Re: [Intel-gfx] [PATCH 19/51] drm: Cleanups after drmm_add_final_kfree rollout
On Thu, Apr 2, 2020 at 2:50 AM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> (On a side note, git-format-patch accepts a -v argument to specify the
> version, I didn't realize you were not aware of it :-))
>
> On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> > A few things:
> > - Update the example driver in the documentation.
> > - We can drop the old kfree in drm_dev_release.
> > - Add a WARN_ON check in drm_dev_register to make sure everyone calls
> > drmm_add_final_kfree and there's no leaks.
> >
> > v2: Restore the full cleanup, I accidentally left some moved code
> > behind when fixing the bisectability of the series.
> >
> > Acked-by: Sam Ravnborg
> > Acked-by: Thomas Zimmermann
> > Cc: Sam Ravnborg
> > Cc: Dan Carpenter
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 12 +---
> > 1 file changed, 5 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 877ded348b6e..7f9d7ea543a0 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -297,8 +297,6 @@ void drm_minor_release(struct drm_minor *minor)
> > *
> > * drm_mode_config_cleanup(drm);
> > * drm_dev_fini(drm);
> > - * kfree(priv->userspace_facing);
> > - * kfree(priv);
> > * }
> > *
> > * static struct drm_driver driver_drm_driver = {
> > @@ -326,10 +324,11 @@ void drm_minor_release(struct drm_minor *minor)
> > * kfree(drm);
> > * return ret;
> > * }
> > + * drmm_add_final_kfree(drm, priv);
> > *
> > * drm_mode_config_init(drm);
> > *
> > - * priv->userspace_facing = kzalloc(..., GFP_KERNEL);
> > + * priv->userspace_facing = drmm_kzalloc(..., GFP_KERNEL);
> > * if (!priv->userspace_facing)
> > * return -ENOMEM;
> > *
> > @@ -837,10 +836,7 @@ static void drm_dev_release(struct kref *ref)
> >
> > drm_managed_release(dev);
> >
> > - if (!dev->driver->release && !dev->managed.final_kfree) {
> > - WARN_ON(!list_empty(>managed.resources));
> > - kfree(dev);
> > - } else if (dev->managed.final_kfree)
> > + if (dev->managed.final_kfree)
> > kfree(dev->managed.final_kfree);
> > }
> >
> > @@ -961,6 +957,8 @@ int drm_dev_register(struct drm_device *dev, unsigned
> > long flags)
> > if (!driver->load)
> > drm_mode_config_validate(dev);
> >
> > + WARN_ON(!dev->managed.final_kfree);
>
> That's too aggressive. Driver freeing their private object in .release()
> isn't wrong. I'd even go as far as saying that it should be the norm,
> until we manage to find a better way to handle that (which this series
> doesn't achieve). Many drivers need to allocate resources at probe time
> before they get a chance to init the drm device. Those resources must be
> released in the error handling paths of probe. By requiring
> drmm_add_final_kfree(), you're making that much more complex. I can't
> release those resources in the error path anymore after calling
> drmm_add_final_kfree(), or they will be released twice. And I can't rely
> on drmm_* to release them in all cases, as the error path may be hit
> before touching anything drm-related.
>
> Until we figure out a good way forward and test it on a significant
> number of drivers, let's not add WARN_ON() that will be hit with the
> majority of drivers, forcing them to be converted to something that is
> clearly half-baked.
Hm, is this conjecture, or did you actually hit this WARN_ON with a
driver? Because I did audit them all, none should hit this, all are
fixed up.
Also, I'm now actually going through all the places where I've added
the drmm_add_final_kfree and remove it again, they are _all_ about 5
lines after the kzalloc that allocates the driver structure which has
drm_device embedded.
So I'd like to understand where you get your seemingly rather sure
convinction from that this is a horrible mistake here ...
/me confused
-Daniel
>
> > +
> > if (drm_dev_needs_global_mutex(dev))
> > mutex_lock(_global_mutex);
> >
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/13] drm/i915: Eliminate port sync copy pasta
On Fri, 2020-03-13 at 18:48 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the copy pasted port sync crtc enable functions and instead
> just split the normal function into the two parts we need.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 128 +++
>
> 1 file changed, 45 insertions(+), 83 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 292cac64f1ac..b56a5a49418f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14909,11 +14909,13 @@ static void intel_pipe_fastset(const struct
> intel_crtc_state *old_crtc_state,
> }
>
> static void commit_pipe_config(struct intel_atomic_state *state,
> -struct intel_crtc_state *old_crtc_state,
> -struct intel_crtc_state *new_crtc_state)
> +struct intel_crtc *crtc)
> {
> - struct intel_crtc *crtc = to_intel_crtc(new_crtc_state-
> >uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> bool modeset = needs_modeset(new_crtc_state);
>
> /*
> @@ -14939,22 +14941,35 @@ static void commit_pipe_config(struct
> intel_atomic_state *state,
> dev_priv->display.atomic_update_watermarks(state,
> crtc);
> }
>
> -static void intel_update_crtc(struct intel_crtc *crtc,
> - struct intel_atomic_state *state,
> - struct intel_crtc_state *old_crtc_state,
> - struct intel_crtc_state *new_crtc_state)
> +static void intel_enable_crtc(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> +
> + if (!needs_modeset(new_crtc_state))
> + return;
> +
> + intel_crtc_update_active_timings(new_crtc_state);
> +
> + dev_priv->display.crtc_enable(state, crtc);
> +
> + /* vblanks work again, re-enable pipe CRC. */
> + intel_crtc_enable_pipe_crc(crtc);
> +}
> +
> +static void intel_update_crtc(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
> + struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> bool modeset = needs_modeset(new_crtc_state);
>
> - if (modeset) {
> - intel_crtc_update_active_timings(new_crtc_state);
> -
> - dev_priv->display.crtc_enable(state, crtc);
> -
> - /* vblanks work again, re-enable pipe CRC. */
> - intel_crtc_enable_pipe_crc(crtc);
> - } else {
> + if (!modeset) {
> if (new_crtc_state->preload_luts &&
> (new_crtc_state->uapi.color_mgmt_changed ||
>new_crtc_state->update_pipe))
> @@ -14974,7 +14989,7 @@ static void intel_update_crtc(struct
> intel_crtc *crtc,
> /* Perform vblank evasion around commit operation */
> intel_pipe_update_start(new_crtc_state);
>
> - commit_pipe_config(state, old_crtc_state, new_crtc_state);
> + commit_pipe_config(state, crtc);
>
> if (INTEL_GEN(dev_priv) >= 9)
> skl_update_planes_on_crtc(state, crtc);
> @@ -15081,30 +15096,19 @@ static void
> intel_commit_modeset_disables(struct intel_atomic_state *state)
>
> static void intel_commit_modeset_enables(struct intel_atomic_state
> *state)
> {
> + struct intel_crtc_state *new_crtc_state;
> struct intel_crtc *crtc;
> - struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> int i;
>
> - for_each_oldnew_intel_crtc_in_state(state, crtc,
> old_crtc_state, new_crtc_state, i) {
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state,
> i) {
> if (!new_crtc_state->hw.active)
> continue;
>
> - intel_update_crtc(crtc, state, old_crtc_state,
> - new_crtc_state);
> + intel_enable_crtc(state, crtc);
> + intel_update_crtc(state, crtc);
> }
> }
>
> -static void intel_crtc_enable_trans_port_sync(struct intel_crtc
> *crtc,
> - struct intel_atomic_state
> *state,
> -
Re: [Intel-gfx] [PATCH 12/13] drm/i915: Pass atomic state to encoder hooks
On Fri, 2020-03-13 at 18:48 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're going to want access to the atomic state for iterating
> the slave crtcs when enabling the port sync master crtc. Pass
> the atomic state all the way down.
>
> The alternative would be yet another encoder hook which we'll
> have to call after all the normal modeset stuff is done. Not
> really a fan of yet another hook just for this.
>
> Note that during readout state sanitation we are now going
> to pass NULL as the atomic state since we don't have one.
> We need to change that and then we can also s/crtc_state/crtc/
> and s/conn_state/conn/ for the encoder hooks as well.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 15 ++--
> drivers/gpu/drm/i915/display/intel_crt.c | 33 ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 89 -
> --
> drivers/gpu/drm/i915/display/intel_ddi.h | 3 +-
> drivers/gpu/drm/i915/display/intel_display.c | 26 --
> .../drm/i915/display/intel_display_types.h| 21 +++--
> drivers/gpu/drm/i915/display/intel_dp.c | 55 +++-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 21 +++--
> drivers/gpu/drm/i915/display/intel_dvo.c | 9 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 3 +-
> drivers/gpu/drm/i915/display/intel_hdcp.h | 4 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 59 +++-
> drivers/gpu/drm/i915/display/intel_lvds.c | 22 +++--
> drivers/gpu/drm/i915/display/intel_panel.c| 3 +-
> drivers/gpu/drm/i915/display/intel_panel.h| 3 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 17 ++--
> drivers/gpu/drm/i915/display/intel_tv.c | 9 +-
> drivers/gpu/drm/i915/display/vlv_dsi.c| 12 ++-
> 18 files changed, 260 insertions(+), 144 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 17cee6f80d8b..ea9907c3e5ba 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1088,7 +1088,8 @@ static void gen11_dsi_powerup_panel(struct
> intel_encoder *encoder)
> wait_for_cmds_dispatched_to_panel(encoder);
> }
>
> -static void gen11_dsi_pre_pll_enable(struct intel_encoder *encoder,
> +static void gen11_dsi_pre_pll_enable(struct intel_atomic_state
> *state,
> + struct intel_encoder *encoder,
>const struct intel_crtc_state
> *crtc_state,
>const struct drm_connector_state
> *conn_state)
> {
> @@ -1099,7 +1100,8 @@ static void gen11_dsi_pre_pll_enable(struct
> intel_encoder *encoder,
> gen11_dsi_program_esc_clk_div(encoder, crtc_state);
> }
>
> -static void gen11_dsi_pre_enable(struct intel_encoder *encoder,
> +static void gen11_dsi_pre_enable(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
>const struct intel_crtc_state
> *pipe_config,
>const struct drm_connector_state
> *conn_state)
> {
> @@ -1118,7 +1120,8 @@ static void gen11_dsi_pre_enable(struct
> intel_encoder *encoder,
> gen11_dsi_set_transcoder_timings(encoder, pipe_config);
> }
>
> -static void gen11_dsi_enable(struct intel_encoder *encoder,
> +static void gen11_dsi_enable(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
>const struct intel_crtc_state *crtc_state,
>const struct drm_connector_state
> *conn_state)
> {
> @@ -1264,7 +1267,8 @@ static void gen11_dsi_disable_io_power(struct
> intel_encoder *encoder)
> }
> }
>
> -static void gen11_dsi_disable(struct intel_encoder *encoder,
> +static void gen11_dsi_disable(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> const struct intel_crtc_state
> *old_crtc_state,
> const struct drm_connector_state
> *old_conn_state)
> {
> @@ -1290,7 +1294,8 @@ static void gen11_dsi_disable(struct
> intel_encoder *encoder,
> gen11_dsi_disable_io_power(encoder);
> }
>
> -static void gen11_dsi_post_disable(struct intel_encoder *encoder,
> +static void gen11_dsi_post_disable(struct intel_atomic_state *state,
> +struct intel_encoder *encoder,
> const struct intel_crtc_state
> *old_crtc_state,
> const struct drm_connector_state
> *old_conn_state)
> {
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> b/drivers/gpu/drm/i915/display/intel_crt.c
> index 78f9b6cde810..80c91404046f 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -203,27 +203,31 @@ static void
Re: [Intel-gfx] [PATCH 6/6] drm/i915/tc/tgl: Implement TC cold sequences
On Thu, Apr 02, 2020 at 02:36:53AM +0300, Souza, Jose wrote:
> On Wed, 2020-04-01 at 15:55 +0300, Imre Deak wrote:
> > On Tue, Mar 31, 2020 at 05:41:20PM -0700, José Roberto de Souza
> > wrote:
> > > TC ports can enter in TCCOLD to save power and is required to
> > > request
> > > to PCODE to exit this state before use or read to TC registers.
> > >
> > > For TGL there is a new MBOX command to do that with a parameter to
> > > ask
> > > PCODE to exit and block TCCOLD entry or unblock TCCOLD entry.
> > >
> > > So adding a new power domain to reuse the refcount and only allow
> > > TC cold when all TC ports are not in use.
> > >
> > > BSpec: 49294
> > > Cc: Imre Deak
> > > Cc: Cooper Chiou
> > > Cc: Kai-Heng Feng
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > .../drm/i915/display/intel_display_power.c| 46 ++
> > > .../drm/i915/display/intel_display_power.h| 1 +
> > > drivers/gpu/drm/i915/display/intel_tc.c | 63
> > > +++
> > > drivers/gpu/drm/i915/display/intel_tc.h | 1 +
> > > drivers/gpu/drm/i915/i915_reg.h | 3 +
> > > 5 files changed, 103 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > index 1ccd57d645c7..5de115583146 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > @@ -2842,6 +2842,8 @@ void intel_display_power_put(struct
> > > drm_i915_private *dev_priv,
> > > #define TGL_AUX_I_TBT6_IO_POWER_DOMAINS (\
> > > BIT_ULL(POWER_DOMAIN_AUX_I_TBT))
> > >
> > > +#define TGL_TC_COLD_OFF (BIT_ULL(POWER_DOMAIN_TC_COLD_OFF))
> >
> > TGL_TC_COLD_OFF_POWER_DOMAINS
>
> Okay
>
> > and should also include all the AUX power domains.
>
> So we would call intel_display_power_get() in intel_tc with aux domain
> instead of POWER_DOMAIN_TC_COLD_OFF?
No, but we also need to block tc-cold whenever getting an AUX power
reference.
> > > +
> > > static const struct i915_power_well_ops
> > > i9xx_always_on_power_well_ops = {
> > > .sync_hw = i9xx_power_well_sync_hw_noop,
> > > .enable = i9xx_always_on_power_well_noop,
> > > @@ -3944,6 +3946,44 @@ static const struct i915_power_well_desc
> > > ehl_power_wells[] = {
> > > },
> > > };
> > >
> > > +static void
> > > +tgl_tc_cold_off_power_well_enable(struct drm_i915_private *i915,
> > > + struct i915_power_well *power_well)
> > > +{
> > > + intel_tc_tgl_tc_cold_request(i915, true);
> > > +}
> > > +
> > > +static void
> > > +tgl_tc_cold_off_power_well_disable(struct drm_i915_private *i915,
> > > +struct i915_power_well *power_well)
> > > +{
> > > + intel_tc_tgl_tc_cold_request(i915, false);
> > > +}
> > > +
> > > +static void
> > > +tgl_tc_cold_off_power_well_sync_hw(struct drm_i915_private *i915,
> > > +struct i915_power_well *power_well)
> > > +{
> > > + if (power_well->count > 0)
> > > + tgl_tc_cold_off_power_well_enable(i915, power_well);
> > > + else
> > > + tgl_tc_cold_off_power_well_disable(i915, power_well);
> > > +}
> > > +
> > > +static bool tgl_tc_cold_off_power_well_is_enabled(struct
> > > drm_i915_private *dev_priv,
> > > + struct
> > > i915_power_well *power_well)
> > > +{
> > > + /* There is no way to just read it from PCODE */
> > > + return false;
> > > +}
> > > +
> > > +static const struct i915_power_well_ops tgl_tc_cold_off_ops = {
> > > + .sync_hw = tgl_tc_cold_off_power_well_sync_hw,
> > > + .enable = tgl_tc_cold_off_power_well_enable,
> > > + .disable = tgl_tc_cold_off_power_well_disable,
> > > + .is_enabled = tgl_tc_cold_off_power_well_is_enabled,
> > > +};
> > > +
> > > static const struct i915_power_well_desc tgl_power_wells[] = {
> > > {
> > > .name = "always-on",
> > > @@ -4271,6 +4311,12 @@ static const struct i915_power_well_desc
> > > tgl_power_wells[] = {
> > > .hsw.irq_pipe_mask = BIT(PIPE_D),
> > > },
> > > },
> > > + {
> > > + .name = "TC cold off",
> > > + .domains = POWER_DOMAIN_TC_COLD_OFF,
> >
> > TGL_TC_COLD_OFF_POWER_DOMAINS
> >
> > > + .ops = _tc_cold_off_ops,
> > > + .id = DISP_PW_ID_NONE,
> > > + },
> > > };
> > >
> > > static int
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> > > b/drivers/gpu/drm/i915/display/intel_display_power.h
> > > index da64a5edae7a..070457e7b948 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> > > @@ -76,6 +76,7 @@ enum intel_display_power_domain {
> > > POWER_DOMAIN_MODESET,
> > > POWER_DOMAIN_GT_IRQ,
> > > POWER_DOMAIN_DPLL_DC_OFF,
> > > + POWER_DOMAIN_TC_COLD_OFF,
> > > POWER_DOMAIN_INIT,
> > >
> > > POWER_DOMAIN_NUM,
> > > diff --git
Re: [Intel-gfx] [PATCH 5/6] drm/i915/tc/icl: Implement TC cold sequences
On Thu, Apr 02, 2020 at 01:35:30AM +0300, Souza, Jose wrote:
> On Wed, 2020-04-01 at 15:43 +0300, Imre Deak wrote:
> > On Tue, Mar 31, 2020 at 05:41:19PM -0700, José Roberto de Souza
> > wrote:
> > > This is required for legacy/static TC ports as IOM is not aware of
> > > the connection and will not trigger the TC cold exit.
> > >
> > > Just request PCODE to exit TCCOLD is not enough as it could enter
> > > again be driver makes use of the port, to prevent it BSpec states
> > > that
> > > aux powerwell should be held.
> > >
> > > So here embedding the TC cold exit sequence into ICL aux enable,
> > > it will enable aux, request tc cold exit and depending in the TC
> > > live
> > > state continue with the regular aux enable sequence.
> > >
> > > And then turning on aux power well during tc lock and turning off
> > > during unlock both depending into the TC port refcount.
> > >
> > > BSpec: 21750
> > > Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1296
> > > Cc: Imre Deak
> > > Cc: Cooper Chiou
> > > Cc: Kai-Heng Feng
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > >
> > > Will run some tests in the office with TBT dockstation to check if
> > > it will be a issue keep both aux enabled. Otherwise more changes
> > > will
> > > be required here.
> > >
> > > .../drm/i915/display/intel_display_power.c| 12 -
> > > .../drm/i915/display/intel_display_types.h| 1 +
> > > drivers/gpu/drm/i915/display/intel_tc.c | 47
> > > ++-
> > > drivers/gpu/drm/i915/display/intel_tc.h | 2 +
> > > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > > 5 files changed, 59 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > index dbd61517ba63..1ccd57d645c7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > @@ -592,9 +592,17 @@ icl_tc_phy_aux_power_well_enable(struct
> > > drm_i915_private *dev_priv,
> > >
> > > _hsw_power_well_enable(dev_priv, power_well);
> > >
> > > - /* TODO ICL TC cold handling */
> > > + if (INTEL_GEN(dev_priv) == 11)
> >
> > Should be if (ICL && dig_port->tc_legacy_port)
>
> Makes sence.
> Oh so we could use it on __intel_tc_port_lock() too and
> don't do this stuff for non legacy ports. Until we get a report of a
> system with a wrong VBT :P
Yes, it's a loss of the vendor shipping a corrupt VBT. But we'll print
an error and fix up the flag.
> > > + intel_tc_icl_tc_cold_exit(dev_priv);
> > >
> > > - _hsw_power_well_continue_enable(dev_priv, power_well);
> > > + /*
> > > + * To avoid power well enable timeouts when disconnected or in
> > > TBT mode
> > > + * when doing the TC cold exit sequence for GEN11
> > > + */
> > > + if (INTEL_GEN(dev_priv) != 11 ||
> > > + (intel_tc_port_live_status_mask(dig_port) &
> > > + (TC_PORT_LEGACY | TC_PORT_DP_ALT)))
> > > + _hsw_power_well_continue_enable(dev_priv, power_well);
> >
> > Why can't we call this unconditionally?
>
> Because we are requesting aux power of regular TC ports as part of tc
> cold exit sequence, if the port is disconnected it will timeout in
> hsw_wait_for_power_well_enable().
>
> Anyways it is wrong as it is not
> taking care of TBT ports, so changing to: if (INTEL_GEN(dev_priv) != 11
> || !dig_port->tc_legacy_port || intel_tc_port_live_status_mask())
What I thought is that the legacy AUX power request will ack after the
PCODE request completes, regardless of whether the sink is connected or
not. If that is not the case then let's just suppress the timeout for
legacy AUX power wells the same way we do that for TBT AUX. I don't like
to make the above call conditional on the live status flag, as that can
change at any moment. So in either case let's make the above call
unconditional.
> > >
> > > if (INTEL_GEN(dev_priv) >= 12 && !power_well->desc-
> > > >hsw.is_tc_tbt) {
Could you check your email client, so that it doesn't wrap lines?
> > > enum tc_port tc_port;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 176ab5f1e867..a9a4a3c1b4d7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -1391,6 +1391,7 @@ struct intel_digital_port {
> > > enum intel_display_power_domain ddi_io_power_domain;
> > > struct mutex tc_lock; /* protects the TypeC port mode */
> > > intel_wakeref_t tc_lock_wakeref;
> > > + intel_wakeref_t tc_cold_wakeref;
> > > int tc_link_refcount;
> > > bool tc_legacy_port:1;
> > > char tc_port_name[8];
> > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > index d944be935423..b6d67f069ef7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > >
Re: [Intel-gfx] [PATCH v2 07/13] drm/i915: Store cpu_transcoder_mask in device info
On Wed, 2020-03-18 at 19:02 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have a bunch of code that would like to know which
> CPU transcoders are actually present in the hardware. Rather than
> use various ad-hoc methods let's just include a full bitmask in
> the device info, alongside pipe_mask.
>
> v2: Rebase
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++--
> drivers/gpu/drm/i915/display/intel_display.c | 13 ++---
> drivers/gpu/drm/i915/display/intel_display.h | 8 --
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_pci.c | 23 +++-
> drivers/gpu/drm/i915/intel_device_info.c | 29
>
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> 7 files changed, 53 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 8bb6c583abb8..0fea2ec2cdd8 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1689,7 +1689,7 @@ bool intel_ddi_connector_get_hw_state(struct
> intel_connector *intel_connector)
> goto out;
> }
>
> - if (HAS_TRANSCODER_EDP(dev_priv) && port == PORT_A)
> + if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP) && port == PORT_A)
> cpu_transcoder = TRANSCODER_EDP;
> else
> cpu_transcoder = (enum transcoder) pipe;
> @@ -1751,7 +1751,7 @@ static void intel_ddi_get_encoder_pipes(struct
> intel_encoder *encoder,
> if (!(tmp & DDI_BUF_CTL_ENABLE))
> goto out;
>
> - if (HAS_TRANSCODER_EDP(dev_priv) && port == PORT_A) {
> + if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP) && port == PORT_A)
> {
> tmp = intel_de_read(dev_priv,
> TRANS_DDI_FUNC_CTL(TRANSCODER_EDP))
> ;
>
> @@ -4076,7 +4076,7 @@ static int intel_ddi_compute_config(struct
> intel_encoder *encoder,
> enum port port = encoder->port;
> int ret;
>
> - if (HAS_TRANSCODER_EDP(dev_priv) && port == PORT_A)
> + if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP) && port == PORT_A)
> pipe_config->cpu_transcoder = TRANSCODER_EDP;
>
> if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_HDMI)) {
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4840988dc58d..292cac64f1ac 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10855,7 +10855,7 @@ static bool hsw_get_transcoder_state(struct
> intel_crtc *crtc,
> panel_transcoder_mask |=
> BIT(TRANSCODER_DSI_0) | BIT(TRANSCODER_DSI_1);
>
> - if (HAS_TRANSCODER_EDP(dev_priv))
> + if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP))
> panel_transcoder_mask |= BIT(TRANSCODER_EDP);
>
> /*
> @@ -18712,15 +18712,6 @@ void
> intel_modeset_driver_remove_noirq(struct drm_i915_private *i915)
>
> #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
>
> -static bool
> -has_transcoder(struct drm_i915_private *dev_priv, enum transcoder
> cpu_transcoder)
> -{
> - if (cpu_transcoder == TRANSCODER_EDP)
> - return HAS_TRANSCODER_EDP(dev_priv);
> - else
> - return INTEL_INFO(dev_priv)->pipe_mask &
> BIT(cpu_transcoder);
> -}
> -
> struct intel_display_error_state {
>
> u32 power_well_driver;
> @@ -18829,7 +18820,7 @@ intel_display_capture_error_state(struct
> drm_i915_private *dev_priv)
> for (i = 0; i < ARRAY_SIZE(error->transcoder); i++) {
> enum transcoder cpu_transcoder = transcoders[i];
>
> - if (!has_transcoder(dev_priv, cpu_transcoder))
> + if (!HAS_TRANSCODER(dev_priv, cpu_transcoder))
> continue;
>
> error->transcoder[i].available = true;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index adb1225a3480..cc7f287804d7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -320,9 +320,13 @@ enum phy_fia {
> for_each_pipe(__dev_priv, __p) \
> for_each_if((__mask) & BIT(__p))
>
> -#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
> +#define for_each_cpu_transcoder(__dev_priv, __t) \
> for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
> - for_each_if ((__mask) & (1 << (__t)))
> + for_each_if (INTEL_INFO(__dev_priv)-
> >cpu_transcoder_mask & BIT(__t))
> +
> +#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
> + for_each_cpu_transcoder(__dev_priv, __t) \
> + for_each_if ((__mask) & BIT(__t))
>
> #define for_each_universal_plane(__dev_priv, __pipe, __p)
> \
> for ((__p) = 0;
Re: [Intel-gfx] [PATCH 19/51] drm: Cleanups after drmm_add_final_kfree rollout
Hi Daniel,
(On a side note, git-format-patch accepts a -v argument to specify the
version, I didn't realize you were not aware of it :-))
On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> A few things:
> - Update the example driver in the documentation.
> - We can drop the old kfree in drm_dev_release.
> - Add a WARN_ON check in drm_dev_register to make sure everyone calls
> drmm_add_final_kfree and there's no leaks.
>
> v2: Restore the full cleanup, I accidentally left some moved code
> behind when fixing the bisectability of the series.
>
> Acked-by: Sam Ravnborg
> Acked-by: Thomas Zimmermann
> Cc: Sam Ravnborg
> Cc: Dan Carpenter
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_drv.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 877ded348b6e..7f9d7ea543a0 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -297,8 +297,6 @@ void drm_minor_release(struct drm_minor *minor)
> *
> * drm_mode_config_cleanup(drm);
> * drm_dev_fini(drm);
> - * kfree(priv->userspace_facing);
> - * kfree(priv);
> * }
> *
> * static struct drm_driver driver_drm_driver = {
> @@ -326,10 +324,11 @@ void drm_minor_release(struct drm_minor *minor)
> * kfree(drm);
> * return ret;
> * }
> + * drmm_add_final_kfree(drm, priv);
> *
> * drm_mode_config_init(drm);
> *
> - * priv->userspace_facing = kzalloc(..., GFP_KERNEL);
> + * priv->userspace_facing = drmm_kzalloc(..., GFP_KERNEL);
> * if (!priv->userspace_facing)
> * return -ENOMEM;
> *
> @@ -837,10 +836,7 @@ static void drm_dev_release(struct kref *ref)
>
> drm_managed_release(dev);
>
> - if (!dev->driver->release && !dev->managed.final_kfree) {
> - WARN_ON(!list_empty(>managed.resources));
> - kfree(dev);
> - } else if (dev->managed.final_kfree)
> + if (dev->managed.final_kfree)
> kfree(dev->managed.final_kfree);
> }
>
> @@ -961,6 +957,8 @@ int drm_dev_register(struct drm_device *dev, unsigned
> long flags)
> if (!driver->load)
> drm_mode_config_validate(dev);
>
> + WARN_ON(!dev->managed.final_kfree);
That's too aggressive. Driver freeing their private object in .release()
isn't wrong. I'd even go as far as saying that it should be the norm,
until we manage to find a better way to handle that (which this series
doesn't achieve). Many drivers need to allocate resources at probe time
before they get a chance to init the drm device. Those resources must be
released in the error handling paths of probe. By requiring
drmm_add_final_kfree(), you're making that much more complex. I can't
release those resources in the error path anymore after calling
drmm_add_final_kfree(), or they will be released twice. And I can't rely
on drmm_* to release them in all cases, as the error path may be hit
before touching anything drm-related.
Until we figure out a good way forward and test it on a significant
number of drivers, let's not add WARN_ON() that will be hit with the
majority of drivers, forcing them to be converted to something that is
clearly half-baked.
> +
> if (drm_dev_needs_global_mutex(dev))
> mutex_lock(_global_mutex);
>
--
Regards,
Laurent Pinchart
___
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/gem: Drop cached obj->bind_count (rev3)
== Series Details ==
Series: drm/i915/gem: Drop cached obj->bind_count (rev3)
URL : https://patchwork.freedesktop.org/series/74593/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8235 -> Patchwork_17173
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17173/index.html
Known issues
Here are the changes found in Patchwork_17173 that come from known issues:
### IGT changes ###
Possible fixes
* {igt@gem_exec_parallel@engines@contexts}:
- {fi-tgl-dsi}: [INCOMPLETE][1] ([i915#529]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8235/fi-tgl-dsi/igt@gem_exec_parallel@engi...@contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17173/fi-tgl-dsi/igt@gem_exec_parallel@engi...@contexts.html
Warnings
* igt@debugfs_test@read_all_entries:
- fi-kbl-x1275: [DMESG-WARN][3] ([i915#62] / [i915#92]) ->
[DMESG-WARN][4] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8235/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17173/fi-kbl-x1275/igt@debugfs_test@read_all_entries.html
* igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275: [DMESG-WARN][5] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][6] ([i915#62] / [i915#92]) +5 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8235/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17173/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#529]: https://gitlab.freedesktop.org/drm/intel/issues/529
[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 (47 -> 38)
--
Additional (3): fi-gdg-551 fi-cfl-8109u fi-skl-6700k2
Missing(12): fi-ilk-m540 fi-bdw-samus fi-bdw-5557u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-elk-e7500 fi-bsw-kefka fi-kbl-7560u fi-byt-clapper
fi-skl-6600u fi-snb-2600
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8235 -> Patchwork_17173
CI-20190529: 20190529
CI_DRM_8235: 8e658041c38badcc50eb074ae0797989fe1fa776 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5556: 311cb1b360b7ae00fab80b822cd34fd512f08ce9 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17173: c3b89dcced3239d5ac1cffcb2a6b4110ba062370 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c3b89dcced32 drm/i915/gem: Drop cached obj->bind_count
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17173/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/8] drm/i915: Flatten a bunch of the pfit functions
On Wed, Feb 12, 2020 at 06:17:34PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Most of the pfit functions are of the form:
>
> func()
> {
> if (pfit_enabled) {
> ...
> }
> }
>
> Flip the pfit_enabled check around to flatten the functions.
>
> And while we're touching all this let's do the usual
> s/pipe_config/crtc_state/ replacement.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 233 +--
> 1 file changed, 115 insertions(+), 118 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index becc6322b7dc..796e27c4aece 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6233,42 +6233,42 @@ static void skl_pfit_enable(const struct
> intel_crtc_state *crtc_state)
> enum pipe pipe = crtc->pipe;
> const struct intel_crtc_scaler_state *scaler_state =
> _state->scaler_state;
> + u16 uv_rgb_hphase, uv_rgb_vphase;
> + int pfit_w, pfit_h, hscale, vscale;
> + unsigned long irqflags;
> + int id;
>
> - if (crtc_state->pch_pfit.enabled) {
> - u16 uv_rgb_hphase, uv_rgb_vphase;
> - int pfit_w, pfit_h, hscale, vscale;
> - unsigned long irqflags;
> - int id;
> + if (!crtc_state->pch_pfit.enabled)
> + return;
>
> - if (WARN_ON(crtc_state->scaler_state.scaler_id < 0))
> - return;
> + if (WARN_ON(crtc_state->scaler_state.scaler_id < 0))
> + return;
>
> - pfit_w = (crtc_state->pch_pfit.size >> 16) & 0x;
> - pfit_h = crtc_state->pch_pfit.size & 0x;
> + pfit_w = (crtc_state->pch_pfit.size >> 16) & 0x;
> + pfit_h = crtc_state->pch_pfit.size & 0x;
>
> - hscale = (crtc_state->pipe_src_w << 16) / pfit_w;
> - vscale = (crtc_state->pipe_src_h << 16) / pfit_h;
> + hscale = (crtc_state->pipe_src_w << 16) / pfit_w;
> + vscale = (crtc_state->pipe_src_h << 16) / pfit_h;
>
> - uv_rgb_hphase = skl_scaler_calc_phase(1, hscale, false);
> - uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
> + uv_rgb_hphase = skl_scaler_calc_phase(1, hscale, false);
> + uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
>
> - id = scaler_state->scaler_id;
> + id = scaler_state->scaler_id;
>
> - spin_lock_irqsave(_priv->uncore.lock, irqflags);
> + spin_lock_irqsave(_priv->uncore.lock, irqflags);
>
> - intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), PS_SCALER_EN
> |
> - PS_FILTER_MEDIUM |
> scaler_state->scalers[id].mode);
> - intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id),
> - PS_Y_PHASE(0) |
> PS_UV_RGB_PHASE(uv_rgb_vphase));
> - intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id),
> - PS_Y_PHASE(0) |
> PS_UV_RGB_PHASE(uv_rgb_hphase));
> - intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(pipe, id),
> - crtc_state->pch_pfit.pos);
> - intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(pipe, id),
> - crtc_state->pch_pfit.size);
> + intel_de_write_fw(dev_priv, SKL_PS_CTRL(pipe, id), PS_SCALER_EN |
> + PS_FILTER_MEDIUM | scaler_state->scalers[id].mode);
> + intel_de_write_fw(dev_priv, SKL_PS_VPHASE(pipe, id),
> + PS_Y_PHASE(0) | PS_UV_RGB_PHASE(uv_rgb_vphase));
> + intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id),
> + PS_Y_PHASE(0) | PS_UV_RGB_PHASE(uv_rgb_hphase));
> + intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(pipe, id),
> + crtc_state->pch_pfit.pos);
> + intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(pipe, id),
> + crtc_state->pch_pfit.size);
>
> - spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> - }
> + spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
> }
>
> static void ilk_pfit_enable(const struct intel_crtc_state *crtc_state)
> @@ -6277,22 +6277,23 @@ static void ilk_pfit_enable(const struct
> intel_crtc_state *crtc_state)
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum pipe pipe = crtc->pipe;
>
> - if (crtc_state->pch_pfit.enabled) {
> - /* Force use of hard-coded filter coefficients
> - * as some pre-programmed values are broken,
> - * e.g. x201.
> - */
> - if (IS_IVYBRIDGE(dev_priv) || IS_HASWELL(dev_priv))
> - intel_de_write(dev_priv, PF_CTL(pipe),
> -PF_ENABLE | PF_FILTER_MED_3x3 |
> PF_PIPE_SEL_IVB(pipe));
> - else
> -
Re: [Intel-gfx] [PATCH 6/6] drm/i915/tc/tgl: Implement TC cold sequences
On Wed, 2020-04-01 at 15:55 +0300, Imre Deak wrote:
> On Tue, Mar 31, 2020 at 05:41:20PM -0700, José Roberto de Souza
> wrote:
> > TC ports can enter in TCCOLD to save power and is required to
> > request
> > to PCODE to exit this state before use or read to TC registers.
> >
> > For TGL there is a new MBOX command to do that with a parameter to
> > ask
> > PCODE to exit and block TCCOLD entry or unblock TCCOLD entry.
> >
> > So adding a new power domain to reuse the refcount and only allow
> > TC cold when all TC ports are not in use.
> >
> > BSpec: 49294
> > Cc: Imre Deak
> > Cc: Cooper Chiou
> > Cc: Kai-Heng Feng
> > Signed-off-by: José Roberto de Souza
> > ---
> > .../drm/i915/display/intel_display_power.c| 46 ++
> > .../drm/i915/display/intel_display_power.h| 1 +
> > drivers/gpu/drm/i915/display/intel_tc.c | 63
> > +++
> > drivers/gpu/drm/i915/display/intel_tc.h | 1 +
> > drivers/gpu/drm/i915/i915_reg.h | 3 +
> > 5 files changed, 103 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 1ccd57d645c7..5de115583146 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -2842,6 +2842,8 @@ void intel_display_power_put(struct
> > drm_i915_private *dev_priv,
> > #define TGL_AUX_I_TBT6_IO_POWER_DOMAINS ( \
> > BIT_ULL(POWER_DOMAIN_AUX_I_TBT))
> >
> > +#define TGL_TC_COLD_OFF (BIT_ULL(POWER_DOMAIN_TC_COLD_OFF))
>
> TGL_TC_COLD_OFF_POWER_DOMAINS
Okay
> and should also include all the AUX power domains.
So we would call intel_display_power_get() in intel_tc with aux domain
instead of POWER_DOMAIN_TC_COLD_OFF?
>
> > +
> > static const struct i915_power_well_ops
> > i9xx_always_on_power_well_ops = {
> > .sync_hw = i9xx_power_well_sync_hw_noop,
> > .enable = i9xx_always_on_power_well_noop,
> > @@ -3944,6 +3946,44 @@ static const struct i915_power_well_desc
> > ehl_power_wells[] = {
> > },
> > };
> >
> > +static void
> > +tgl_tc_cold_off_power_well_enable(struct drm_i915_private *i915,
> > + struct i915_power_well *power_well)
> > +{
> > + intel_tc_tgl_tc_cold_request(i915, true);
> > +}
> > +
> > +static void
> > +tgl_tc_cold_off_power_well_disable(struct drm_i915_private *i915,
> > + struct i915_power_well *power_well)
> > +{
> > + intel_tc_tgl_tc_cold_request(i915, false);
> > +}
> > +
> > +static void
> > +tgl_tc_cold_off_power_well_sync_hw(struct drm_i915_private *i915,
> > + struct i915_power_well *power_well)
> > +{
> > + if (power_well->count > 0)
> > + tgl_tc_cold_off_power_well_enable(i915, power_well);
> > + else
> > + tgl_tc_cold_off_power_well_disable(i915, power_well);
> > +}
> > +
> > +static bool tgl_tc_cold_off_power_well_is_enabled(struct
> > drm_i915_private *dev_priv,
> > + struct
> > i915_power_well *power_well)
> > +{
> > + /* There is no way to just read it from PCODE */
> > + return false;
> > +}
> > +
> > +static const struct i915_power_well_ops tgl_tc_cold_off_ops = {
> > + .sync_hw = tgl_tc_cold_off_power_well_sync_hw,
> > + .enable = tgl_tc_cold_off_power_well_enable,
> > + .disable = tgl_tc_cold_off_power_well_disable,
> > + .is_enabled = tgl_tc_cold_off_power_well_is_enabled,
> > +};
> > +
> > static const struct i915_power_well_desc tgl_power_wells[] = {
> > {
> > .name = "always-on",
> > @@ -4271,6 +4311,12 @@ static const struct i915_power_well_desc
> > tgl_power_wells[] = {
> > .hsw.irq_pipe_mask = BIT(PIPE_D),
> > },
> > },
> > + {
> > + .name = "TC cold off",
> > + .domains = POWER_DOMAIN_TC_COLD_OFF,
>
> TGL_TC_COLD_OFF_POWER_DOMAINS
>
> > + .ops = _tc_cold_off_ops,
> > + .id = DISP_PW_ID_NONE,
> > + },
> > };
> >
> > static int
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> > b/drivers/gpu/drm/i915/display/intel_display_power.h
> > index da64a5edae7a..070457e7b948 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> > @@ -76,6 +76,7 @@ enum intel_display_power_domain {
> > POWER_DOMAIN_MODESET,
> > POWER_DOMAIN_GT_IRQ,
> > POWER_DOMAIN_DPLL_DC_OFF,
> > + POWER_DOMAIN_TC_COLD_OFF,
> > POWER_DOMAIN_INIT,
> >
> > POWER_DOMAIN_NUM,
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > b/drivers/gpu/drm/i915/display/intel_tc.c
> > index b6d67f069ef7..58f19037411a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > @@ -507,11 +507,16 @@ static void __intel_tc_port_lock(struct
> > intel_digital_port *dig_port,
> >
> >
Re: [Intel-gfx] [PATCH v2 3/8] drm/i915: Fix skl+ non-scaled pfit modes
On Wed, Feb 12, 2020 at 06:17:33PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fix skl_update_scaler_crtc() to deal with different scaling
> modes correctly. The current implementation assumes
> DRM_MODE_SCALE_FULLSCREEN. Fortunately we don't expose any
> border properties currently so the code does actually end
> up doing the right thing (assigning a scaler for pfit).
> The code does need to be fixed before any borders are
> exposed.
>
> Also we have redundant calls to skl_update_scaler_crtc() in
> dp/hdmi .compute_config() which can be nuked. They were anyway
> called before we had even computed the pfit state so were
> basically nonsense. The real call we need to keep is in
> intel_crtc_atomic_check().
>
> v2: Deal witrh skl_update_scaler_crtc() in intel_dp_ycbcr420_config()
>
> Signed-off-by: Ville Syrjälä
Just keeping the call in intel_crtc_atomic_check() looks good
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 40 ++--
> drivers/gpu/drm/i915/display/intel_display.h | 1 -
> drivers/gpu/drm/i915/display/intel_dp.c | 15
> drivers/gpu/drm/i915/display/intel_hdmi.c| 6 ---
> 4 files changed, 19 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index de50aa0b076c..becc6322b7dc 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6101,30 +6101,28 @@ skl_update_scaler(struct intel_crtc_state
> *crtc_state, bool force_detach,
> return 0;
> }
>
> -/**
> - * skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
> - *
> - * @state: crtc's scaler state
> - *
> - * Return
> - * 0 - scaler_usage updated successfully
> - *error - requested scaling cannot be supported or other error condition
> - */
> -int skl_update_scaler_crtc(struct intel_crtc_state *state)
> +static int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state)
> {
> - const struct drm_display_mode *adjusted_mode = >hw.adjusted_mode;
> - bool need_scaler = false;
> + const struct drm_display_mode *adjusted_mode =
> + _state->hw.adjusted_mode;
> + int width, height;
>
> - if (state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> - state->pch_pfit.enabled)
> - need_scaler = true;
> + if (crtc_state->pch_pfit.enabled) {
> + u32 pfit_size = crtc_state->pch_pfit.size;
> +
> + width = pfit_size >> 16;
> + height = pfit_size & 0x;
> + } else {
> + width = adjusted_mode->crtc_hdisplay;
> + height = adjusted_mode->crtc_vdisplay;
> + }
>
> - return skl_update_scaler(state, !state->hw.active, SKL_CRTC_INDEX,
> - >scaler_state.scaler_id,
> - state->pipe_src_w, state->pipe_src_h,
> - adjusted_mode->crtc_hdisplay,
> - adjusted_mode->crtc_vdisplay, NULL, 0,
> - need_scaler);
> + return skl_update_scaler(crtc_state, !crtc_state->hw.active,
> + SKL_CRTC_INDEX,
> + _state->scaler_state.scaler_id,
> + crtc_state->pipe_src_w, crtc_state->pipe_src_h,
> + width, height, NULL, 0,
> + crtc_state->pch_pfit.enabled);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 75438a136d58..6291d3dbc513 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -584,7 +584,6 @@ void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
> struct intel_crtc_state *crtc_state);
>
> u16 skl_scaler_calc_phase(int sub, int scale, bool chroma_center);
> -int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state);
> void skl_scaler_disable(const struct intel_crtc_state *old_crtc_state);
> void ilk_pfit_disable(const struct intel_crtc_state *old_crtc_state);
> u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f4dede6253f8..a827eac8acc2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2307,7 +2307,6 @@ intel_dp_ycbcr420_config(struct intel_dp *intel_dp,
> const struct drm_display_mode *adjusted_mode =
> _state->hw.adjusted_mode;
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> - int ret;
>
> if (!drm_mode_is_420_only(info, adjusted_mode) ||
> !intel_dp_get_colorimetry_status(intel_dp) ||
> @@ -2316,13 +2315,6 @@
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Drop cached obj->bind_count (rev3)
== Series Details == Series: drm/i915/gem: Drop cached obj->bind_count (rev3) URL : https://patchwork.freedesktop.org/series/74593/ State : warning == Summary == $ dim checkpatch origin/drm-tip c3b89dcced32 drm/i915/gem: Drop cached obj->bind_count -:160: WARNING:LONG_LINE: line over 100 characters #160: FILE: drivers/gpu/drm/i915/i915_debugfs.c:285: + seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu inactive, %llu closed)\n", \ total: 0 errors, 1 warnings, 0 checks, 228 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/23] perf/core: Only copy-to-user after completely unlocking all locks.
On Wed, Apr 01, 2020 at 11:55:28AM -0700, Nick Desaulniers wrote: > On Tue, Mar 31, 2020 at 11:50 PM kbuild test robot wrote: > > > > Hi Maarten, > > > > I love your patch! Perhaps something to improve: > > > > [auto build test WARNING on drm-tip/drm-tip] > > [also build test WARNING on next-20200331] > > [cannot apply to drm-intel/for-linux-next tip/perf/core v5.6] > > [if your patch is applied to the wrong git tree, please drop us a note to > > help > > improve the system. BTW, we also suggest to use '--base' option to specify > > the > > base tree in git format-patch, please see > > https://stackoverflow.com/a/37406982] > > > > url: > > https://github.com/0day-ci/linux/commits/Maarten-Lankhorst/Revert-drm-i915-gem-Drop-relocation-slowpath/20200401-005710 > > base: git://anongit.freedesktop.org/drm/drm-tip drm-tip > > config: x86_64-randconfig-d003-20200331 (attached as .config) > > compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project > > 5227fa0c72ce55927cf4849160acb00442489937) > > reproduce: > > wget > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > > ~/bin/make.cross > > chmod +x ~/bin/make.cross > > # save the attached .config to linux build tree > > COMPILER=clang make.cross ARCH=x86_64 > > > > If you fix the issue, kindly add following tag > > Reported-by: kbuild test robot > > > > All warnings (new ones prefixed by >>): > > > > >> kernel/events/core.o: warning: objtool: perf_read()+0x306: stack state > > >> mismatch: reg1[3]=-2-56 reg2[3]=-1+0 > > Apologies Maarten, this objtool warning looks like maybe a compiler > bug for us to fix. > > Philip, I tried to reproduce by cloning > git://anongit.freedesktop.org/drm/drm-tip, but I don't understand the > URL in the report. Were Maarten's patches on top of drm-tip? Is Hi Nick, this is report for patch we receive from the mailing list, so the patch series is applied on "git://anongit.freedesktop.org/drm/drm-tip drm-tip", and form a branch at "https://github.com/0day-ci/linux/commits/Maarten-Lankhorst/Revert-drm-i915-gem-Drop-relocation-slowpath/20200401-005710;. The url is the real code to be checked out that can be used to reproduce. Thanks > there a tree you found them from (rather than me fetching the 0day > branch on github)? (Or maybe this is what a report looks like for a > series posted to the list?) Apologies for the naivete, but I plan to > triage as many of these reports on the Clang side as I can in my free > time, so I want to make sure I understand precisely what failure is > occurring where and how. > -- > Thanks, > ~Nick Desaulniers ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] kernel 5.6: baytrail hdmi audio not working
Hi, on my Intel Compute Stick STCK1 (baytrail hdmi audio) sound is not working with the kernel 5.6 I have bisected the kernel and I found the commit that introduced the issue: commit 58d124ea2739e1440ddd743d46c470fe724aca9a Author: Maarten Lankhorst Date: Thu Oct 31 12:26:04 2019 +0100 drm/i915: Complete crtc hw/uapi split, v6. Now that we separated everything into uapi and hw, it's time to make the split definitive. Remove the union and make a copy of the hw state on modeset and fastset. Color blobs are copied in crtc atomic_check(), right before color management is checked. If more information is required please let me know. Giacomo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Parametrize PFIT_PIPE
On Wed, Feb 12, 2020 at 07:43:51PM +0200, Jani Nikula wrote:
> On Wed, 12 Feb 2020, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make the PFIT_PIPE stuff less ugly via parametrization.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_panel.c | 3 +--
> > drivers/gpu/drm/i915/i915_reg.h| 1 +
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> > b/drivers/gpu/drm/i915/display/intel_panel.c
> > index cba2f1c2557f..8b0730f4c442 100644
> > --- a/drivers/gpu/drm/i915/display/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> > @@ -434,8 +434,7 @@ void intel_gmch_panel_fitting(struct intel_crtc
> > *intel_crtc,
> > /* 965+ wants fuzzy fitting */
> > /* FIXME: handle multiple panels by failing gracefully */
> > if (INTEL_GEN(dev_priv) >= 4)
> > - pfit_control |= ((intel_crtc->pipe << PFIT_PIPE_SHIFT) |
> > -PFIT_FILTER_FUZZY);
> > + pfit_control |= PFIT_PIPE(intel_crtc->pipe) | PFIT_FILTER_FUZZY;
> >
> > out:
> > if ((pfit_control & PFIT_ENABLE) == 0) {
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index b09c1d6dc0aa..faf8945a51b0 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4928,6 +4928,7 @@ enum {
> > #define PFIT_ENABLE (1 << 31)
> > #define PFIT_PIPE_MASK (3 << 29)
> > #define PFIT_PIPE_SHIFT 29
> > +#define PFIT_PIPE(pipe) ((pipe) << 29)
>
> This is fine, but might have as well defined this in terms of
> REG_FIELD_PREP. I especially like it for parametrized stuff because it
> ensures we don't flood the value outside the field.
>
> Reviewed-by: Jani Nikula
Was just reviewing this series and noticed that Jani had suggested using
REG_FIELD_PREP stuff here, are you going to change that Ville?
Looks good otherwise
Manasi
>
> > #define VERT_INTERP_DISABLE (0 << 10)
> > #define VERT_INTERP_BILINEAR (1 << 10)
> > #define VERT_INTERP_MASK (3 << 10)
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> 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
[Intel-gfx] [CI] drm/i915/gem: Drop cached obj->bind_count
We cached the number of vma bound to the object in order to speed up
shrinker decisions. This has been superseded by being more proactive in
removing objects we cannot shrink from the shrinker lists, and so we can
drop the clumsy attempt at atomically counting the bind count and
comparing it to the number of pinned mappings of the object. This will
only get more clumsier with asynchronous binding and unbinding.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 -
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 ---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 --
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 18 ++---
.../drm/i915/gem/selftests/i915_gem_mman.c| 4 ---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ++---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 7 -
drivers/gpu/drm/i915/i915_vma.c | 24 -
.../gpu/drm/i915/selftests/i915_gem_evict.c | 26 +--
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 1 -
12 files changed, 13 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 0cc40e77bbd2..af43e82f45c7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -369,7 +369,7 @@ static void i915_gem_object_bump_inactive_ggtt(struct
drm_i915_gem_object *obj)
struct i915_vma *vma;
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
- if (!atomic_read(>bind_count))
+ if (list_empty(>vma.list))
return;
mutex_lock(>ggtt.vm.mutex);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 5da9f9e534b9..3f01cdd1a39b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -206,7 +206,6 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
}
obj->mmo.offsets = RB_ROOT;
- GEM_BUG_ON(atomic_read(>bind_count));
GEM_BUG_ON(obj->userfault_count);
GEM_BUG_ON(!list_empty(>lut_list));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index a0b10bcd8d8a..54ee658bb168 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -179,9 +179,6 @@ struct drm_i915_gem_object {
#define TILING_MASK (FENCE_MINIMUM_STRIDE - 1)
#define STRIDE_MASK (~TILING_MASK)
- /** Count of VMA actually bound by this object */
- atomic_t bind_count;
-
struct {
/*
* Protects the pages and their use. Do not use directly, but
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 24f4cadea114..5d855fcd5c0f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -199,8 +199,6 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object
*obj)
if (i915_gem_object_has_pinned_pages(obj))
return -EBUSY;
- GEM_BUG_ON(atomic_read(>bind_count));
-
/* May be called by shrinker from within get_pages() (on another bo) */
mutex_lock(>mm.lock);
if (unlikely(atomic_read(>mm.pages_pin_count))) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 03e5eb4c99d1..5b65ce738b16 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -26,18 +26,6 @@ static bool can_release_pages(struct drm_i915_gem_object
*obj)
if (!i915_gem_object_is_shrinkable(obj))
return false;
- /*
-* Only report true if by unbinding the object and putting its pages
-* we can actually make forward progress towards freeing physical
-* pages.
-*
-* If the pages are pinned for any other reason than being bound
-* to the GPU, simply unbinding from the GPU is not going to succeed
-* in releasing our pin count on the pages themselves.
-*/
- if (atomic_read(>mm.pages_pin_count) >
atomic_read(>bind_count))
- return false;
-
/*
* We can only return physical pages to the system if we can either
* discard the contents (because the user has marked them as being
@@ -54,6 +42,8 @@ static bool unsafe_drop_pages(struct drm_i915_gem_object *obj,
flags = 0;
if (shrink & I915_SHRINK_ACTIVE)
flags = I915_GEM_OBJECT_UNBIND_ACTIVE;
+ if (!(shrink & I915_SHRINK_BOUND))
+ flags = I915_GEM_OBJECT_UNBIND_TEST;
if
Re: [Intel-gfx] [PATCH 5/6] drm/i915/tc/icl: Implement TC cold sequences
On Wed, 2020-04-01 at 15:43 +0300, Imre Deak wrote:
> On Tue, Mar 31, 2020 at 05:41:19PM -0700, José Roberto de Souza
> wrote:
> > This is required for legacy/static TC ports as IOM is not aware of
> > the connection and will not trigger the TC cold exit.
> >
> > Just request PCODE to exit TCCOLD is not enough as it could enter
> > again be driver makes use of the port, to prevent it BSpec states
> > that
> > aux powerwell should be held.
> >
> > So here embedding the TC cold exit sequence into ICL aux enable,
> > it will enable aux, request tc cold exit and depending in the TC
> > live
> > state continue with the regular aux enable sequence.
> >
> > And then turning on aux power well during tc lock and turning off
> > during unlock both depending into the TC port refcount.
> >
> > BSpec: 21750
> > Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1296
> > Cc: Imre Deak
> > Cc: Cooper Chiou
> > Cc: Kai-Heng Feng
> > Signed-off-by: José Roberto de Souza
> > ---
> >
> > Will run some tests in the office with TBT dockstation to check if
> > it will be a issue keep both aux enabled. Otherwise more changes
> > will
> > be required here.
> >
> > .../drm/i915/display/intel_display_power.c| 12 -
> > .../drm/i915/display/intel_display_types.h| 1 +
> > drivers/gpu/drm/i915/display/intel_tc.c | 47
> > ++-
> > drivers/gpu/drm/i915/display/intel_tc.h | 2 +
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > 5 files changed, 59 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index dbd61517ba63..1ccd57d645c7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -592,9 +592,17 @@ icl_tc_phy_aux_power_well_enable(struct
> > drm_i915_private *dev_priv,
> >
> > _hsw_power_well_enable(dev_priv, power_well);
> >
> > - /* TODO ICL TC cold handling */
> > + if (INTEL_GEN(dev_priv) == 11)
>
> Should be if (ICL && dig_port->tc_legacy_port)
Makes sence.
Oh so we could use it on __intel_tc_port_lock() too and
don't do this stuff for non legacy ports. Until we get a report of a
system with a wrong VBT :P
>
> > + intel_tc_icl_tc_cold_exit(dev_priv);
> >
> > - _hsw_power_well_continue_enable(dev_priv, power_well);
> > + /*
> > +* To avoid power well enable timeouts when disconnected or in
> > TBT mode
> > +* when doing the TC cold exit sequence for GEN11
> > +*/
> > + if (INTEL_GEN(dev_priv) != 11 ||
> > + (intel_tc_port_live_status_mask(dig_port) &
> > +(TC_PORT_LEGACY | TC_PORT_DP_ALT)))
> > + _hsw_power_well_continue_enable(dev_priv, power_well);
>
> Why can't we call this unconditionally?
Because we are requesting aux power of regular TC ports as part of tc
cold exit sequence, if the port is disconnected it will timeout in
hsw_wait_for_power_well_enable().
Anyways it is wrong as it is not
taking care of TBT ports, so changing to: if (INTEL_GEN(dev_priv) != 11
|| !dig_port->tc_legacy_port || intel_tc_port_live_status_mask())
>
> >
> > if (INTEL_GEN(dev_priv) >= 12 && !power_well->desc-
> > >hsw.is_tc_tbt) {
> > enum tc_port tc_port;
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 176ab5f1e867..a9a4a3c1b4d7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1391,6 +1391,7 @@ struct intel_digital_port {
> > enum intel_display_power_domain ddi_io_power_domain;
> > struct mutex tc_lock; /* protects the TypeC port mode */
> > intel_wakeref_t tc_lock_wakeref;
> > + intel_wakeref_t tc_cold_wakeref;
> > int tc_link_refcount;
> > bool tc_legacy_port:1;
> > char tc_port_name[8];
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > b/drivers/gpu/drm/i915/display/intel_tc.c
> > index d944be935423..b6d67f069ef7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > @@ -7,6 +7,7 @@
> > #include "intel_display.h"
> > #include "intel_display_types.h"
> > #include "intel_dp_mst.h"
> > +#include "intel_sideband.h"
> > #include "intel_tc.h"
> >
> > static const char *tc_port_mode_name(enum tc_port_mode mode)
> > @@ -506,6 +507,13 @@ static void __intel_tc_port_lock(struct
> > intel_digital_port *dig_port,
> >
> > mutex_lock(_port->tc_lock);
> >
> > + if (INTEL_GEN(i915) == 11 && dig_port->tc_link_refcount == 0) {
> > + enum intel_display_power_domain aux_domain;
> > +
> > + aux_domain = intel_aux_ch_to_power_domain(dig_port-
> > >aux_ch);
> > + dig_port->tc_cold_wakeref =
> > intel_display_power_get(i915, aux_domain);
> > + }
> > +
>
> It would be enough to hold this ref only for the
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence
== Series Details == Series: series starting with [CI,1/3] drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence URL : https://patchwork.freedesktop.org/series/75383/ State : success == Summary == CI Bug Log - changes from CI_DRM_8234 -> Patchwork_17172 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17172/index.html Known issues Here are the changes found in Patchwork_17172 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@active: - fi-icl-y: [PASS][1] -> [DMESG-FAIL][2] ([i915#765]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8234/fi-icl-y/igt@i915_selftest@l...@active.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17172/fi-icl-y/igt@i915_selftest@l...@active.html * igt@i915_selftest@live@execlists: - fi-icl-y: [PASS][3] -> [DMESG-FAIL][4] ([i915#1314]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8234/fi-icl-y/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17172/fi-icl-y/igt@i915_selftest@l...@execlists.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [DMESG-FAIL][5] ([i915#62] / [i915#95]) -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8234/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17172/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_flip@basic-flip-vs-wf_vblank: - fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92]) -> [DMESG-WARN][8] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8234/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vblank.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17172/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-wf_vblank.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][10] ([i915#62] / [i915#92]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8234/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17172/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1314]: https://gitlab.freedesktop.org/drm/intel/issues/1314 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#765]: https://gitlab.freedesktop.org/drm/intel/issues/765 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (46 -> 37) -- Additional (4): fi-hsw-peppy fi-gdg-551 fi-bsw-kefka fi-kbl-r Missing(13): fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u fi-bdw-gvtdvm fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-skl-lmem fi-bdw-samus fi-byt-n2820 fi-byt-clapper fi-skl-6600u Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8234 -> Patchwork_17172 CI-20190529: 20190529 CI_DRM_8234: 5fef6faaa3ca8d62bc01e07c7737c2c6d6296817 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5556: 311cb1b360b7ae00fab80b822cd34fd512f08ce9 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17172: 32e647fb1bc0e7fae2bbbf54703182a45b446047 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 32e647fb1bc0 drm/i915/gt: Make fence revocation unequivocal e64a5dc6c8cd drm/i915/gt: Store the fence details on the fence 141fb6b1ac25 drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17172/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence
Only GPU activity via the GGTT fence is asynchronous, we know that we
control the CPU access directly, so we only need to wait for the GPU to
stop using the fence before we relinquish it.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 25
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 3 +++
drivers/gpu/drm/i915/i915_vma.c | 4
3 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 225970f4a4ef..d527b11ddfb7 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -223,6 +223,11 @@ static void fence_write(struct i915_fence_reg *fence,
fence->dirty = false;
}
+static bool gpu_uses_fence_registers(struct i915_fence_reg *fence)
+{
+ return INTEL_GEN(fence_to_i915(fence)) < 4;
+}
+
static int fence_update(struct i915_fence_reg *fence,
struct i915_vma *vma)
{
@@ -239,15 +244,18 @@ static int fence_update(struct i915_fence_reg *fence,
if (!i915_vma_is_map_and_fenceable(vma))
return -EINVAL;
- ret = i915_vma_sync(vma);
- if (ret)
- return ret;
+ if (gpu_uses_fence_registers(fence)) {
+ /* implicit 'unfenced' GPU blits */
+ ret = i915_vma_sync(vma);
+ if (ret)
+ return ret;
+ }
}
old = xchg(>vma, NULL);
if (old) {
/* XXX Ideally we would move the waiting to outside the mutex */
- ret = i915_vma_sync(old);
+ ret = i915_active_wait(>active);
if (ret) {
fence->vma = old;
return ret;
@@ -869,6 +877,7 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
for (i = 0; i < num_fences; i++) {
struct i915_fence_reg *fence = >fence_regs[i];
+ i915_active_init(>active, NULL, NULL);
fence->ggtt = ggtt;
fence->id = i;
list_add_tail(>link, >fence_list);
@@ -880,6 +889,14 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
void intel_ggtt_fini_fences(struct i915_ggtt *ggtt)
{
+ int i;
+
+ for (i = 0; i < ggtt->num_fences; i++) {
+ struct i915_fence_reg *fence = >fence_regs[i];
+
+ i915_active_fini(>active);
+ }
+
kfree(ggtt->fence_regs);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
index 9850f6a85d2a..08c6bb667581 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
@@ -28,6 +28,8 @@
#include
#include
+#include "i915_active.h"
+
struct drm_i915_gem_object;
struct i915_ggtt;
struct i915_vma;
@@ -41,6 +43,7 @@ struct i915_fence_reg {
struct i915_ggtt *ggtt;
struct i915_vma *vma;
atomic_t pin_count;
+ struct i915_active active;
int id;
/**
* Whether the tiling parameters for the currently
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 18069df2a9e5..616ca5a7c875 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1232,6 +1232,10 @@ int i915_vma_move_to_active(struct i915_vma *vma,
dma_resv_add_shared_fence(vma->resv, >fence);
obj->write_domain = 0;
}
+
+ if (flags & EXEC_OBJECT_NEEDS_FENCE && vma->fence)
+ i915_active_add_request(>fence->active, rq);
+
obj->read_domains |= I915_GEM_GPU_DOMAINS;
obj->mm.dirty = true;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/3] drm/i915/gt: Make fence revocation unequivocal
If we must revoke the fence because the VMA is no longer present, or
because the fence no longer applies, ensure that we do and convert it
into an error if we try but cannot.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 21 +++-
drivers/gpu/drm/i915/i915_gem.c | 12 +--
drivers/gpu/drm/i915/i915_vma.c | 4 +---
drivers/gpu/drm/i915/i915_vma.h | 2 +-
4 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index b5b2ef52e570..7fb36b12fe7a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -298,23 +298,26 @@ static int fence_update(struct i915_fence_reg *fence,
*
* This function force-removes any fence from the given object, which is useful
* if the kernel wants to do untiled GTT access.
- *
- * Returns:
- *
- * 0 on success, negative error code on failure.
*/
-int i915_vma_revoke_fence(struct i915_vma *vma)
+void i915_vma_revoke_fence(struct i915_vma *vma)
{
struct i915_fence_reg *fence = vma->fence;
+ intel_wakeref_t wakeref;
lockdep_assert_held(>vm->mutex);
if (!fence)
- return 0;
+ return;
- if (atomic_read(>pin_count))
- return -EBUSY;
+ GEM_BUG_ON(fence->vma != vma);
+ GEM_BUG_ON(!i915_active_is_idle(>active));
+ GEM_BUG_ON(atomic_read(>pin_count));
+
+ fence->tiling = 0;
+ WRITE_ONCE(fence->vma, NULL);
+ vma->fence = NULL;
- return fence_update(fence, NULL);
+ with_intel_runtime_pm_if_in_use(fence_to_uncore(fence)->rpm, wakeref)
+ fence_write(fence);
}
static struct i915_fence_reg *fence_find(struct i915_ggtt *ggtt)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 762b50b08d73..b0836fc47ae6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -993,18 +993,16 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
return ERR_PTR(ret);
}
+ ret = i915_vma_pin(vma, size, alignment, flags | PIN_GLOBAL);
+ if (ret)
+ return ERR_PTR(ret);
+
if (vma->fence && !i915_gem_object_is_tiled(obj)) {
mutex_lock(>vm.mutex);
- ret = i915_vma_revoke_fence(vma);
+ i915_vma_revoke_fence(vma);
mutex_unlock(>vm.mutex);
- if (ret)
- return ERR_PTR(ret);
}
- ret = i915_vma_pin(vma, size, alignment, flags | PIN_GLOBAL);
- if (ret)
- return ERR_PTR(ret);
-
ret = i915_vma_wait_for_bind(vma);
if (ret) {
i915_vma_unpin(vma);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 616ca5a7c875..b5f78b0acf5d 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1298,9 +1298,7 @@ int __i915_vma_unbind(struct i915_vma *vma)
i915_vma_flush_writes(vma);
/* release the fence reg _after_ flushing */
- ret = i915_vma_revoke_fence(vma);
- if (ret)
- return ret;
+ i915_vma_revoke_fence(vma);
/* Force a pagefault for domain tracking on next user access */
i915_vma_revoke_mmap(vma);
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index b958ad07f212..8ad1daabcd58 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -326,7 +326,7 @@ static inline struct page *i915_vma_first_page(struct
i915_vma *vma)
* True if the vma has a fence, false otherwise.
*/
int __must_check i915_vma_pin_fence(struct i915_vma *vma);
-int __must_check i915_vma_revoke_fence(struct i915_vma *vma);
+void i915_vma_revoke_fence(struct i915_vma *vma);
int __i915_vma_pin_fence(struct i915_vma *vma);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915/gt: Store the fence details on the fence
Make a copy of the object tiling parameters at the point of grabbing the
fence.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 93 +++-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 4 +
2 files changed, 37 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index d527b11ddfb7..b5b2ef52e570 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -68,8 +68,7 @@ static struct intel_uncore *fence_to_uncore(struct
i915_fence_reg *fence)
return fence->ggtt->vm.gt->uncore;
}
-static void i965_write_fence_reg(struct i915_fence_reg *fence,
-struct i915_vma *vma)
+static void i965_write_fence_reg(struct i915_fence_reg *fence)
{
i915_reg_t fence_reg_lo, fence_reg_hi;
int fence_pitch_shift;
@@ -87,18 +86,16 @@ static void i965_write_fence_reg(struct i915_fence_reg
*fence,
}
val = 0;
- if (vma) {
- unsigned int stride = i915_gem_object_get_stride(vma->obj);
+ if (fence->tiling) {
+ unsigned int stride = fence->stride;
- GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
- GEM_BUG_ON(!IS_ALIGNED(vma->node.start, I965_FENCE_PAGE));
- GEM_BUG_ON(!IS_ALIGNED(vma->fence_size, I965_FENCE_PAGE));
GEM_BUG_ON(!IS_ALIGNED(stride, 128));
- val = (vma->node.start + vma->fence_size - I965_FENCE_PAGE) <<
32;
- val |= vma->node.start;
+ val = fence->start + fence->size - I965_FENCE_PAGE;
+ val <<= 32;
+ val |= fence->start;
val |= (u64)((stride / 128) - 1) << fence_pitch_shift;
- if (i915_gem_object_get_tiling(vma->obj) == I915_TILING_Y)
+ if (fence->tiling == I915_TILING_Y)
val |= BIT(I965_FENCE_TILING_Y_SHIFT);
val |= I965_FENCE_REG_VALID;
}
@@ -125,21 +122,15 @@ static void i965_write_fence_reg(struct i915_fence_reg
*fence,
}
}
-static void i915_write_fence_reg(struct i915_fence_reg *fence,
-struct i915_vma *vma)
+static void i915_write_fence_reg(struct i915_fence_reg *fence)
{
u32 val;
val = 0;
- if (vma) {
- unsigned int tiling = i915_gem_object_get_tiling(vma->obj);
+ if (fence->tiling) {
+ unsigned int stride = fence->stride;
+ unsigned int tiling = fence->tiling;
bool is_y_tiled = tiling == I915_TILING_Y;
- unsigned int stride = i915_gem_object_get_stride(vma->obj);
-
- GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
- GEM_BUG_ON(vma->node.start & ~I915_FENCE_START_MASK);
- GEM_BUG_ON(!is_power_of_2(vma->fence_size));
- GEM_BUG_ON(!IS_ALIGNED(vma->node.start, vma->fence_size));
if (is_y_tiled && HAS_128_BYTE_Y_TILING(fence_to_i915(fence)))
stride /= 128;
@@ -147,10 +138,10 @@ static void i915_write_fence_reg(struct i915_fence_reg
*fence,
stride /= 512;
GEM_BUG_ON(!is_power_of_2(stride));
- val = vma->node.start;
+ val = fence->start;
if (is_y_tiled)
val |= BIT(I830_FENCE_TILING_Y_SHIFT);
- val |= I915_FENCE_SIZE_BITS(vma->fence_size);
+ val |= I915_FENCE_SIZE_BITS(fence->size);
val |= ilog2(stride) << I830_FENCE_PITCH_SHIFT;
val |= I830_FENCE_REG_VALID;
@@ -165,25 +156,18 @@ static void i915_write_fence_reg(struct i915_fence_reg
*fence,
}
}
-static void i830_write_fence_reg(struct i915_fence_reg *fence,
-struct i915_vma *vma)
+static void i830_write_fence_reg(struct i915_fence_reg *fence)
{
u32 val;
val = 0;
- if (vma) {
- unsigned int stride = i915_gem_object_get_stride(vma->obj);
+ if (fence->tiling) {
+ unsigned int stride = fence->stride;
- GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
- GEM_BUG_ON(vma->node.start & ~I830_FENCE_START_MASK);
- GEM_BUG_ON(!is_power_of_2(vma->fence_size));
- GEM_BUG_ON(!is_power_of_2(stride / 128));
- GEM_BUG_ON(!IS_ALIGNED(vma->node.start, vma->fence_size));
-
- val = vma->node.start;
- if (i915_gem_object_get_tiling(vma->obj) == I915_TILING_Y)
+ val = fence->start;
+ if (fence->tiling == I915_TILING_Y)
val |= BIT(I830_FENCE_TILING_Y_SHIFT);
- val |= I830_FENCE_SIZE_BITS(vma->fence_size);
+ val |= I830_FENCE_SIZE_BITS(fence->size);
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Try allocating va from free space (rev3)
== Series Details == Series: drm/i915/gem: Try allocating va from free space (rev3) URL : https://patchwork.freedesktop.org/series/74748/ State : success == Summary == CI Bug Log - changes from CI_DRM_8233 -> Patchwork_17171 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17171/index.html Known issues Here are the changes found in Patchwork_17171 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [PASS][1] -> [SKIP][2] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17171/fi-kbl-x1275/igt@i915_pm_...@module-reload.html * igt@kms_busy@basic@modeset: - fi-kbl-x1275: [PASS][3] -> [DMESG-FAIL][4] ([i915#62]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-kbl-x1275/igt@kms_busy@ba...@modeset.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17171/fi-kbl-x1275/igt@kms_busy@ba...@modeset.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-cml-u2: [PASS][5] -> [DMESG-WARN][6] ([IGT#4]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-cml-u2/igt@kms_chamel...@common-hpd-after-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17171/fi-cml-u2/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_flip@basic-flip-vs-modeset: - fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92]) +21 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17171/fi-kbl-x1275/igt@kms_f...@basic-flip-vs-modeset.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [PASS][9] -> [DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +9 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17171/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [IGT#4]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/4 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [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 (47 -> 36) -- Additional (2): fi-bdw-gvtdvm fi-gdg-551 Missing(13): fi-tgl-dsi fi-bsw-n3050 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-kbl-7500u fi-ctg-p8600 fi-elk-e7500 fi-skl-lmem fi-bdw-samus fi-byt-clapper fi-skl-6700k2 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8233 -> Patchwork_17171 CI-20190529: 20190529 CI_DRM_8233: 0862243a5514a9da625520bd4f554f8348077594 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5553: 60475d9b41c58b7d256e83c7d53eaf7c2f1f8ecc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17171: ea63499c8e784ef283f7ee9ce0a1e103b07c1174 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ea63499c8e78 drm/i915/gem: Try allocating va from free space == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17171/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gem: Try allocating va from free space
If the current node/entry location is occupied, and the object is not
pinned, try assigning it some free space. We cannot wait here, so if in
doubt, we unreserve and try to grab all at once.
v2: Use the final pin_flags so that we won't have to move the object if
we find the wrong free space.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 68 ---
1 file changed, 43 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 908fb877f875..9d11bad74e9a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -429,6 +429,32 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
return false;
}
+static u64 eb_pin_flags(const struct drm_i915_gem_exec_object2 *entry,
+ unsigned int exec_flags)
+{
+ u64 pin_flags = 0;
+
+ if (exec_flags & EXEC_OBJECT_NEEDS_GTT)
+ pin_flags |= PIN_GLOBAL;
+
+ /*
+* Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset,
+* limit address to the first 4GBs for unflagged objects.
+*/
+ if (!(exec_flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS))
+ pin_flags |= PIN_ZONE_4G;
+
+ if (exec_flags & __EXEC_OBJECT_NEEDS_MAP)
+ pin_flags |= PIN_MAPPABLE;
+
+ if (exec_flags & EXEC_OBJECT_PINNED)
+ pin_flags |= entry->offset | PIN_OFFSET_FIXED;
+ else if (exec_flags & __EXEC_OBJECT_NEEDS_BIAS)
+ pin_flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
+
+ return pin_flags;
+}
+
static inline bool
eb_pin_vma(struct i915_execbuffer *eb,
const struct drm_i915_gem_exec_object2 *entry,
@@ -446,8 +472,19 @@ eb_pin_vma(struct i915_execbuffer *eb,
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
pin_flags |= PIN_GLOBAL;
- if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags)))
- return false;
+ /* Attempt to reuse the current location if available */
+ if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags))) {
+ if (entry->flags & EXEC_OBJECT_PINNED)
+ return false;
+
+ /* Failing that pick any _free_ space if suitable */
+ if (unlikely(i915_vma_pin(vma,
+ entry->pad_to_size,
+ entry->alignment,
+ eb_pin_flags(entry, ev->flags) |
+ PIN_USER | PIN_NOEVICT)))
+ return false;
+ }
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
if (unlikely(i915_vma_pin_fence(vma))) {
@@ -588,28 +625,9 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
u64 pin_flags)
{
struct drm_i915_gem_exec_object2 *entry = ev->exec;
- unsigned int exec_flags = ev->flags;
struct i915_vma *vma = ev->vma;
int err;
- if (exec_flags & EXEC_OBJECT_NEEDS_GTT)
- pin_flags |= PIN_GLOBAL;
-
- /*
-* Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset,
-* limit address to the first 4GBs for unflagged objects.
-*/
- if (!(exec_flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS))
- pin_flags |= PIN_ZONE_4G;
-
- if (exec_flags & __EXEC_OBJECT_NEEDS_MAP)
- pin_flags |= PIN_MAPPABLE;
-
- if (exec_flags & EXEC_OBJECT_PINNED)
- pin_flags |= entry->offset | PIN_OFFSET_FIXED;
- else if (exec_flags & __EXEC_OBJECT_NEEDS_BIAS)
- pin_flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
-
if (drm_mm_node_allocated(>node) &&
eb_vma_misplaced(entry, vma, ev->flags)) {
err = i915_vma_unbind(vma);
@@ -619,7 +637,7 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
err = i915_vma_pin(vma,
entry->pad_to_size, entry->alignment,
- pin_flags);
+ eb_pin_flags(entry, ev->flags) | pin_flags);
if (err)
return err;
@@ -628,7 +646,7 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
eb->args->flags |= __EXEC_HAS_RELOC;
}
- if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
+ if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
err = i915_vma_pin_fence(vma);
if (unlikely(err)) {
i915_vma_unpin(vma);
@@ -636,10 +654,10 @@ static int eb_reserve_vma(const struct i915_execbuffer
*eb,
}
if (vma->fence)
- exec_flags |= __EXEC_OBJECT_HAS_FENCE;
+ ev->flags |= __EXEC_OBJECT_HAS_FENCE;
}
- ev->flags =
Re: ✗ Fi.CI.BAT: failure for drm/i915/gem: Try allocating va from free space (rev2)
Quoting Patchwork (2020-04-01 20:31:15) > == Series Details == > > Series: drm/i915/gem: Try allocating va from free space (rev2) > URL : https://patchwork.freedesktop.org/series/74748/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_8233 -> Patchwork_17170 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_17170 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_17170, 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_17170/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_17170: > > ### IGT changes ### > > Possible regressions > > * igt@gem_busy@busy-all: > - fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-bsw-nick/igt@gem_b...@busy-all.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-bsw-nick/igt@gem_b...@busy-all.html Looks like CI is working! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Try allocating va from free space (rev2)
== Series Details == Series: drm/i915/gem: Try allocating va from free space (rev2) URL : https://patchwork.freedesktop.org/series/74748/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8233 -> Patchwork_17170 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17170 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17170, 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_17170/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17170: ### IGT changes ### Possible regressions * igt@gem_busy@busy-all: - fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-bsw-nick/igt@gem_b...@busy-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-bsw-nick/igt@gem_b...@busy-all.html - fi-bdw-5557u: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-bdw-5557u/igt@gem_b...@busy-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-bdw-5557u/igt@gem_b...@busy-all.html - fi-kbl-8809g: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-kbl-8809g/igt@gem_b...@busy-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-kbl-8809g/igt@gem_b...@busy-all.html - fi-icl-guc: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-icl-guc/igt@gem_b...@busy-all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-icl-guc/igt@gem_b...@busy-all.html - fi-kbl-r: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-kbl-r/igt@gem_b...@busy-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-kbl-r/igt@gem_b...@busy-all.html - fi-icl-dsi: [PASS][11] -> [INCOMPLETE][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-icl-dsi/igt@gem_b...@busy-all.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-icl-dsi/igt@gem_b...@busy-all.html - fi-kbl-guc: [PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-kbl-guc/igt@gem_b...@busy-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-kbl-guc/igt@gem_b...@busy-all.html - fi-kbl-7500u: [PASS][15] -> [INCOMPLETE][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-kbl-7500u/igt@gem_b...@busy-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-kbl-7500u/igt@gem_b...@busy-all.html - fi-kbl-x1275: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-kbl-x1275/igt@gem_b...@busy-all.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-kbl-x1275/igt@gem_b...@busy-all.html - fi-icl-u2: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-icl-u2/igt@gem_b...@busy-all.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-icl-u2/igt@gem_b...@busy-all.html - fi-skl-6600u: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-skl-6600u/igt@gem_b...@busy-all.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-skl-6600u/igt@gem_b...@busy-all.html - fi-cfl-8700k: [PASS][23] -> [INCOMPLETE][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-cfl-8700k/igt@gem_b...@busy-all.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-cfl-8700k/igt@gem_b...@busy-all.html - fi-icl-y: [PASS][25] -> [INCOMPLETE][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-icl-y/igt@gem_b...@busy-all.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-icl-y/igt@gem_b...@busy-all.html - fi-apl-guc: [PASS][27] -> [INCOMPLETE][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-apl-guc/igt@gem_b...@busy-all.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-apl-guc/igt@gem_b...@busy-all.html - fi-ivb-3770:[PASS][29] -> [INCOMPLETE][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8233/fi-ivb-3770/igt@gem_b...@busy-all.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17170/fi-ivb-3770/igt@gem_b...@busy-all.html - fi-cml-s: [PASS][31] -> [INCOMPLETE][32] [31]:
Re: [Intel-gfx] [PATCH 08/11] drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence
On Wed, 1 Apr 2020 at 20:02, Chris Wilson wrote:
>
> Quoting Matthew Auld (2020-04-01 19:56:23)
> > On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
> > >
> > > Only GPU activity via the GGTT fence is asynchronous, we know that we
> > > control the CPU access directly, so we only need to wait for the GPU to
> > > stop using the fence before we relinquish it.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 12
> > > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 3 +++
> > > drivers/gpu/drm/i915/i915_vma.c | 4
> > > 3 files changed, 15 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > > b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > > index 225970f4a4ef..74f8201486b2 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > > @@ -239,15 +239,18 @@ static int fence_update(struct i915_fence_reg
> > > *fence,
> > > if (!i915_vma_is_map_and_fenceable(vma))
> > > return -EINVAL;
> > >
> > > - ret = i915_vma_sync(vma);
> > > - if (ret)
> > > - return ret;
> > > + if (INTEL_GEN(fence_to_i915(fence)) < 4) {
> > > + /* implicit 'unfenced' GPU blits */
> > > + ret = i915_vma_sync(vma);
> >
> > What was the strangeness with gen < 4 again?
>
> From gen4, all gpu ops have implicit fences and never reference the
> global fence registers.
>
> if (gpu_uses_fence_registers())
>
> worksforme
>
> > > + if (ret)
> > > + return ret;
> > > + }
> > > }
> > >
> > > old = xchg(>vma, NULL);
> > > if (old) {
> > > /* XXX Ideally we would move the waiting to outside the
> > > mutex */
> > > - ret = i915_vma_sync(old);
> > > + ret = i915_active_wait(>active);
> > > if (ret) {
> > > fence->vma = old;
> > > return ret;
> > > @@ -869,6 +872,7 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
> > > for (i = 0; i < num_fences; i++) {
> > > struct i915_fence_reg *fence = >fence_regs[i];
> > >
> > > + i915_active_init(>active, NULL, NULL);
> >
> > Some active_fini?
>
> For debug peace of mind, I think we added fini_fences so should be easy
> to type up.
Ok,
Reviewed-by: Matthew Auld
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/11] drm/i915/gem: Drop cached obj->bind_count
On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote: > > We cached the number of vma bound to the object in order to speed up > shrinker decisions. This has been superseded by being more proactive in > removing objects we cannot shrink from the shrinker lists, and so we can > drop the clumsy attempt at atomically counting the bind count and > comparing it to the number of pinned mappings of the object. This will > only get more clumsier with asynchronous binding and unbinding. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/11] drm/i915/gt: Make fence revocation unequivocal
On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote: > > If we must revoke the fence because the VMA is no longer present, or > because the fence no longer applies, ensure that we do and convert it > into an error if we try but cannot. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Try allocating va from free space (rev2)
== Series Details == Series: drm/i915/gem: Try allocating va from free space (rev2) URL : https://patchwork.freedesktop.org/series/74748/ State : warning == Summary == $ dim checkpatch origin/drm-tip f645456d24f7 drm/i915/gem: Try allocating va from free space -:27: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u64' over 'uint64_t' #27: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:435: + uint64_t pin_flags = 0; total: 0 errors, 0 warnings, 1 checks, 109 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/11] drm/i915/gt: Store the fence details on the fence
On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote: > > Make a copy of the object tiling parameters at the point of grabbing the > fence. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/11] drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence
Quoting Matthew Auld (2020-04-01 19:56:23)
> On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
> >
> > Only GPU activity via the GGTT fence is asynchronous, we know that we
> > control the CPU access directly, so we only need to wait for the GPU to
> > stop using the fence before we relinquish it.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 12
> > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 3 +++
> > drivers/gpu/drm/i915/i915_vma.c | 4
> > 3 files changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > index 225970f4a4ef..74f8201486b2 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > @@ -239,15 +239,18 @@ static int fence_update(struct i915_fence_reg *fence,
> > if (!i915_vma_is_map_and_fenceable(vma))
> > return -EINVAL;
> >
> > - ret = i915_vma_sync(vma);
> > - if (ret)
> > - return ret;
> > + if (INTEL_GEN(fence_to_i915(fence)) < 4) {
> > + /* implicit 'unfenced' GPU blits */
> > + ret = i915_vma_sync(vma);
>
> What was the strangeness with gen < 4 again?
>From gen4, all gpu ops have implicit fences and never reference the
global fence registers.
if (gpu_uses_fence_registers())
worksforme
> > + if (ret)
> > + return ret;
> > + }
> > }
> >
> > old = xchg(>vma, NULL);
> > if (old) {
> > /* XXX Ideally we would move the waiting to outside the
> > mutex */
> > - ret = i915_vma_sync(old);
> > + ret = i915_active_wait(>active);
> > if (ret) {
> > fence->vma = old;
> > return ret;
> > @@ -869,6 +872,7 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
> > for (i = 0; i < num_fences; i++) {
> > struct i915_fence_reg *fence = >fence_regs[i];
> >
> > + i915_active_init(>active, NULL, NULL);
>
> Some active_fini?
For debug peace of mind, I think we added fini_fences so should be easy
to type up.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/gem: Try allocating va from free space
If the current node/entry location is occupied, and the object is not
pinned, try assigning it some free space. We cannot wait here, so if in
doubt, we unreserve and try to grab all at once.
v2: Use the final pin_flags so that we won't have to move the object if
we find the wrong free space.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 68 ---
1 file changed, 43 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 908fb877f875..7665a9262433 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -429,6 +429,32 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2
*entry,
return false;
}
+static uint64_t
+eb_pin_flags(const struct drm_i915_gem_exec_object2 *entry)
+{
+ uint64_t pin_flags = 0;
+
+ if (entry->flags & EXEC_OBJECT_NEEDS_GTT)
+ pin_flags |= PIN_GLOBAL;
+
+ /*
+* Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset,
+* limit address to the first 4GBs for unflagged objects.
+*/
+ if (!(entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS))
+ pin_flags |= PIN_ZONE_4G;
+
+ if (entry->flags & __EXEC_OBJECT_NEEDS_MAP)
+ pin_flags |= PIN_MAPPABLE;
+
+ if (entry->flags & EXEC_OBJECT_PINNED)
+ pin_flags |= entry->offset | PIN_OFFSET_FIXED;
+ else if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS)
+ pin_flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
+
+ return pin_flags;
+}
+
static inline bool
eb_pin_vma(struct i915_execbuffer *eb,
const struct drm_i915_gem_exec_object2 *entry,
@@ -446,8 +472,19 @@ eb_pin_vma(struct i915_execbuffer *eb,
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
pin_flags |= PIN_GLOBAL;
- if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags)))
- return false;
+ /* Attempt to reuse the current location if available */
+ if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags))) {
+ if (entry->flags & EXEC_OBJECT_PINNED)
+ return false;
+
+ /* Failing that pick any _free_ space if suitable */
+ if (unlikely(i915_vma_pin(vma,
+ entry->pad_to_size,
+ entry->alignment,
+ eb_pin_flags(entry) |
+ PIN_USER | PIN_NOEVICT)))
+ return false;
+ }
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
if (unlikely(i915_vma_pin_fence(vma))) {
@@ -588,28 +625,9 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
u64 pin_flags)
{
struct drm_i915_gem_exec_object2 *entry = ev->exec;
- unsigned int exec_flags = ev->flags;
struct i915_vma *vma = ev->vma;
int err;
- if (exec_flags & EXEC_OBJECT_NEEDS_GTT)
- pin_flags |= PIN_GLOBAL;
-
- /*
-* Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset,
-* limit address to the first 4GBs for unflagged objects.
-*/
- if (!(exec_flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS))
- pin_flags |= PIN_ZONE_4G;
-
- if (exec_flags & __EXEC_OBJECT_NEEDS_MAP)
- pin_flags |= PIN_MAPPABLE;
-
- if (exec_flags & EXEC_OBJECT_PINNED)
- pin_flags |= entry->offset | PIN_OFFSET_FIXED;
- else if (exec_flags & __EXEC_OBJECT_NEEDS_BIAS)
- pin_flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
-
if (drm_mm_node_allocated(>node) &&
eb_vma_misplaced(entry, vma, ev->flags)) {
err = i915_vma_unbind(vma);
@@ -619,7 +637,7 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
err = i915_vma_pin(vma,
entry->pad_to_size, entry->alignment,
- pin_flags);
+ eb_pin_flags(entry) | pin_flags);
if (err)
return err;
@@ -628,7 +646,7 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
eb->args->flags |= __EXEC_HAS_RELOC;
}
- if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
+ if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
err = i915_vma_pin_fence(vma);
if (unlikely(err)) {
i915_vma_unpin(vma);
@@ -636,10 +654,10 @@ static int eb_reserve_vma(const struct i915_execbuffer
*eb,
}
if (vma->fence)
- exec_flags |= __EXEC_OBJECT_HAS_FENCE;
+ ev->flags |= __EXEC_OBJECT_HAS_FENCE;
}
- ev->flags = exec_flags | __EXEC_OBJECT_HAS_PIN;
+ ev->flags |=
Re: [Intel-gfx] [PATCH 08/11] drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence
On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
>
> Only GPU activity via the GGTT fence is asynchronous, we know that we
> control the CPU access directly, so we only need to wait for the GPU to
> stop using the fence before we relinquish it.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 12
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 3 +++
> drivers/gpu/drm/i915/i915_vma.c | 4
> 3 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> index 225970f4a4ef..74f8201486b2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> @@ -239,15 +239,18 @@ static int fence_update(struct i915_fence_reg *fence,
> if (!i915_vma_is_map_and_fenceable(vma))
> return -EINVAL;
>
> - ret = i915_vma_sync(vma);
> - if (ret)
> - return ret;
> + if (INTEL_GEN(fence_to_i915(fence)) < 4) {
> + /* implicit 'unfenced' GPU blits */
> + ret = i915_vma_sync(vma);
What was the strangeness with gen < 4 again?
> + if (ret)
> + return ret;
> + }
> }
>
> old = xchg(>vma, NULL);
> if (old) {
> /* XXX Ideally we would move the waiting to outside the mutex
> */
> - ret = i915_vma_sync(old);
> + ret = i915_active_wait(>active);
> if (ret) {
> fence->vma = old;
> return ret;
> @@ -869,6 +872,7 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
> for (i = 0; i < num_fences; i++) {
> struct i915_fence_reg *fence = >fence_regs[i];
>
> + i915_active_init(>active, NULL, NULL);
Some active_fini?
> fence->ggtt = ggtt;
> fence->id = i;
> list_add_tail(>link, >fence_list);
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> index 9850f6a85d2a..08c6bb667581 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> @@ -28,6 +28,8 @@
> #include
> #include
>
> +#include "i915_active.h"
> +
> struct drm_i915_gem_object;
> struct i915_ggtt;
> struct i915_vma;
> @@ -41,6 +43,7 @@ struct i915_fence_reg {
> struct i915_ggtt *ggtt;
> struct i915_vma *vma;
> atomic_t pin_count;
> + struct i915_active active;
> int id;
> /**
> * Whether the tiling parameters for the currently
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 18069df2a9e5..616ca5a7c875 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -1232,6 +1232,10 @@ int i915_vma_move_to_active(struct i915_vma *vma,
> dma_resv_add_shared_fence(vma->resv, >fence);
> obj->write_domain = 0;
> }
> +
> + if (flags & EXEC_OBJECT_NEEDS_FENCE && vma->fence)
> + i915_active_add_request(>fence->active, rq);
> +
> obj->read_domains |= I915_GEM_GPU_DOMAINS;
> obj->mm.dirty = true;
>
> --
> 2.20.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
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/23] Revert "drm/i915/gem: Drop relocation slowpath"
== Series Details == Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation slowpath" URL : https://patchwork.freedesktop.org/series/75303/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17153_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17153_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17153_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_17153_full: ### IGT changes ### Possible regressions * igt@gem_close@many-handles-one-vma: - shard-glk: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-glk6/igt@gem_cl...@many-handles-one-vma.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-glk4/igt@gem_cl...@many-handles-one-vma.html - shard-apl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-apl4/igt@gem_cl...@many-handles-one-vma.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-apl7/igt@gem_cl...@many-handles-one-vma.html - shard-skl: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-skl10/igt@gem_cl...@many-handles-one-vma.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-skl2/igt@gem_cl...@many-handles-one-vma.html - shard-tglb: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-tglb2/igt@gem_cl...@many-handles-one-vma.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-tglb7/igt@gem_cl...@many-handles-one-vma.html - shard-kbl: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-kbl3/igt@gem_cl...@many-handles-one-vma.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-kbl4/igt@gem_cl...@many-handles-one-vma.html - shard-snb: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-snb5/igt@gem_cl...@many-handles-one-vma.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-snb6/igt@gem_cl...@many-handles-one-vma.html - shard-iclb: [PASS][13] -> [FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb7/igt@gem_cl...@many-handles-one-vma.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-iclb5/igt@gem_cl...@many-handles-one-vma.html * igt@gem_ctx_freq@sysfs: - shard-apl: [PASS][15] -> [INCOMPLETE][16] +20 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-apl7/igt@gem_ctx_f...@sysfs.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-apl4/igt@gem_ctx_f...@sysfs.html * igt@gem_exec_whisper@basic-fds-all: - shard-iclb: NOTRUN -> [INCOMPLETE][17] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-iclb1/igt@gem_exec_whis...@basic-fds-all.html * igt@perf_pmu@busy-hang-bcs0: - shard-skl: [PASS][18] -> [INCOMPLETE][19] +19 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-skl7/igt@perf_...@busy-hang-bcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-skl9/igt@perf_...@busy-hang-bcs0.html * igt@perf_pmu@busy-idle-vcs0: - shard-skl: NOTRUN -> [INCOMPLETE][20] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-skl4/igt@perf_...@busy-idle-vcs0.html * igt@perf_pmu@busy-start-vecs0: - shard-iclb: [PASS][21] -> [INCOMPLETE][22] +18 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb2/igt@perf_...@busy-start-vecs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-iclb5/igt@perf_...@busy-start-vecs0.html * igt@perf_pmu@busy-vcs0: - shard-kbl: [PASS][23] -> [INCOMPLETE][24] +22 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-kbl3/igt@perf_...@busy-vcs0.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-kbl4/igt@perf_...@busy-vcs0.html * igt@perf_pmu@render-node-busy-rcs0: - shard-tglb: [PASS][25] -> [INCOMPLETE][26] +24 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-tglb1/igt@perf_...@render-node-busy-rcs0.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17153/shard-tglb1/igt@perf_...@render-node-busy-rcs0.html * igt@runner@aborted: - shard-iclb: NOTRUN ->
Re: [Intel-gfx] [PATCH] drm/i915/perf: Enable application triggered OA reports
On Tue, Mar 31, 2020 at 02:46:46PM +0300, Lionel Landwerlin wrote: Gen12 brought an important redesign of the OA unit, splitting it in 2 with a per context part (OAR) and a global part (OAG). OAR deals with per context counters and implements the MI_REPORT_PERF_COUNT command. OAG deals with global counters and the OA buffer. Unfortunately some of the counters available in OAG are not available in OAR, for instance counters that would report global caches utilization. Since applications making use of this want to access those additional OAG counters we can enable them to generate a report from their command buffer into the OA buffer. This is somewhat equivalent to having them doing their own MI_REPORT_PERF_COUNT. The application then parse the OA buffer as they were doing previously, only looking for a begin/end OA report with the appropriate reason field in the OA buffer instead of using MI_REPORT_PERF_COUNT generated reports for begin/end. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 18 ++ drivers/gpu/drm/i915/i915_perf.c| 10 +++--- drivers/gpu/drm/i915/i915_reg.h | 2 ++ 3 files changed, 27 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index e96cc7fa0936..552eadaa6f9a 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1127,6 +1127,10 @@ static void gen9_whitelist_build(struct i915_wa_list *w) /* WaSendPushConstantsFromMMIO:skl,bxt */ whitelist_reg(w, COMMON_SLICE_CHICKEN2); + + /* Allow userspace trigger OA report generation in OA buffer. */ + whitelist_reg(w, OAREPORTTRIG2); + whitelist_reg(w, OAREPORTTRIG6); } static void skl_whitelist_build(struct intel_engine_cs *engine) @@ -1208,6 +1212,10 @@ static void cnl_whitelist_build(struct intel_engine_cs *engine) /* WaEnablePreemptionGranularityControlByUMD:cnl */ whitelist_reg(w, GEN8_CS_CHICKEN1); + + /* Allow userspace trigger OA report generation in OA buffer. */ + whitelist_reg(w, OAREPORTTRIG2); + whitelist_reg(w, OAREPORTTRIG6); } static void icl_whitelist_build(struct intel_engine_cs *engine) @@ -1237,6 +1245,12 @@ static void icl_whitelist_build(struct intel_engine_cs *engine) whitelist_reg_ext(w, PS_INVOCATION_COUNT, RING_FORCE_TO_NONPRIV_ACCESS_RD | RING_FORCE_TO_NONPRIV_RANGE_4); + + /* +* Allow userspace trigger OA report generation in OA buffer. +*/ + whitelist_reg(w, OAREPORTTRIG2); + whitelist_reg(w, OAREPORTTRIG6); break; case VIDEO_DECODE_CLASS: @@ -1281,6 +1295,10 @@ static void tgl_whitelist_build(struct intel_engine_cs *engine) /* Wa_1806527549:tgl */ whitelist_reg(w, HIZ_CHICKEN); + + /* Allow userspace trigger OA report generation in OA buffer. */ + whitelist_reg(w, GEN12_OAG_OAREPORTTRIG2); + whitelist_reg(w, GEN12_OAG_OAREPORTTRIG6); break; default: break; diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index 28e3d76fa2e6..ae935b1b1ae3 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -1450,7 +1450,8 @@ static void gen8_init_oa_buffer(struct i915_perf_stream *stream) * bit." */ intel_uncore_write(uncore, GEN8_OABUFFER, gtt_offset | - OABUFFER_SIZE_16M | GEN8_OABUFFER_MEM_SELECT_GGTT); + OABUFFER_SIZE_16M | GEN8_OABUFFER_MEM_SELECT_GGTT | + GEN8_OABUFFER_EDGE_TRIGGER); intel_uncore_write(uncore, GEN8_OATAILPTR, gtt_offset & GEN8_OATAILPTR_MASK); /* Mark that we need updated tail pointers to read from... */ @@ -1503,7 +1504,8 @@ static void gen12_init_oa_buffer(struct i915_perf_stream *stream) * bit." */ intel_uncore_write(uncore, GEN12_OAG_OABUFFER, gtt_offset | - OABUFFER_SIZE_16M | GEN8_OABUFFER_MEM_SELECT_GGTT); + OABUFFER_SIZE_16M | GEN8_OABUFFER_MEM_SELECT_GGTT | + GEN12_OAG_OABUFFER_EDGE_TRIGGER); intel_uncore_write(uncore, GEN12_OAG_OATAILPTR, gtt_offset & GEN12_OAG_OATAILPTR_MASK); @@ -4481,8 +4483,10 @@ int i915_perf_ioctl_version(void) * * 5: Add DRM_I915_PERF_PROP_POLL_OA_PERIOD parameter that controls the *interval for the hrtimer used to check for OA data. +* +* 6. Add edge trigger report generation support. */ - return 5; + return 6; Do you think we should be adding a comment in uapi for revision 6? If not, this patch looks good and is:
Re: [Intel-gfx] [PATCH 07/11] drm/i915/gem: Try allocating va from free space
Quoting Matthew Auld (2020-04-01 19:20:56)
> On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
> >
> > If the current node/entry location is occupied, and the object is not
> > pinned, try assigning it some free space. We cannot wait here, so if in
> > doubt, we unreserve and try to grab all at once.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index bc8aa9604787..d8c746108d85 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -446,8 +446,17 @@ eb_pin_vma(struct i915_execbuffer *eb,
> > if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
> > pin_flags |= PIN_GLOBAL;
> >
> > - if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags)))
> > - return false;
> > + if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags))) {
> > + if (entry->flags & EXEC_OBJECT_PINNED)
> > + return false;
> > +
> > + pin_flags &= ~PIN_OFFSET_FIXED;
> > + if (unlikely(i915_vma_pin(vma,
> > + entry->pad_to_size,
> > + entry->alignment,
> > + pin_flags)))
>
> Just curious, why not just apply the rest of the flags here(MAP, 48B,
> BIAS etc) which saves us from having to bind/unbind/bind if it's
> trivially misplaced?
That required actually doing some work to refactor the flag selection!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_alignment: Exercise potential priority inversion
From: Dominik Grzegorzek
A low priority client should not block a high priority client. In this
case we check that if a low priority client poisons its own GTT and so
its execbuf may take ages to process, a high priority client can still
execute in parallel.
Signed-off-by: Dominik Grzegorzek
Cc: Zbigniew Kempczyński
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_alignment.c | 116
tests/intel-ci/blacklist.txt| 1 -
2 files changed, 116 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_exec_alignment.c b/tests/i915/gem_exec_alignment.c
index 2895aee1e..730d3b778 100644
--- a/tests/i915/gem_exec_alignment.c
+++ b/tests/i915/gem_exec_alignment.c
@@ -38,6 +38,8 @@
#include
#include
#include
+#include
+#include
#include "drm.h"
@@ -121,6 +123,118 @@ static uint32_t batch_create(int i915, unsigned long sz)
return handle;
}
+static void naughty_child(int i915, int link)
+{
+ struct drm_i915_gem_execbuffer2 execbuf;
+ struct drm_i915_gem_exec_object2 *obj;
+ uint64_t gtt_size, ram_size, count;
+ struct timespec tv = {};
+
+ gtt_size = gem_aperture_size(i915); /* We have to *share* our GTT! */
+ ram_size = intel_get_total_ram_mb();
+ ram_size *= 1024 * 1024;
+
+ count = min(gtt_size, ram_size) / 16384;
+ if (count > file_max()) /* vfs cap */
+ count = file_max();
+ intel_require_memory(count, 4096, CHECK_RAM);
+
+ /* Fill the low-priority address space */
+ obj = calloc(sizeof(*obj), count);
+ igt_assert(obj);
+ for (unsigned long i = 0; i < count; i++) {
+ obj[i].handle = batch_create(i915, 4096);
+ if ((gtt_size - 1) >> 32)
+ obj[i].flags |= EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+ obj[i].alignment = 4096;
+ }
+
+ memset(, 0, sizeof(execbuf));
+ execbuf.buffers_ptr = to_user_pointer(obj);
+ execbuf.buffer_count = count;
+ execbuf.rsvd1 = gem_context_create(i915);
+ gem_execbuf(i915, );
+
+ /* Calibrate a long execbuf() */
+ for (unsigned long i = 0; i < count; i++)
+ obj[i].alignment = 8192;
+
+ execbuf.buffer_count = 2;
+ while (igt_seconds_elapsed() < 2) {
+ execbuf.buffer_count <<= 1;
+ gem_execbuf(i915, );
+ }
+ execbuf.buffer_count <<= 1;
+ if (execbuf.buffer_count > count)
+ execbuf.buffer_count = count;
+ igt_debug("Using %u buffers to delay execbuf\n", execbuf.buffer_count);
+
+ for (unsigned long i = 0; i < count; i++)
+ obj[i].alignment = 16384;
+
+ write(link, , sizeof(tv));
+
+ igt_debug("Executing naughty execbuf\n");
+ igt_nsec_elapsed(memset(, 0, sizeof(tv)));
+ gem_execbuf(i915, ); /* this should take over 2s */
+ igt_info("Naughty client took %'"PRIu64"ns\n",
+igt_nsec_elapsed());
+
+ gem_context_destroy(i915, execbuf.rsvd1);
+ for (unsigned long i = 0; i < count; i++)
+ gem_close(i915, obj[i].handle);
+ free(obj);
+}
+
+static void prio_inversion(int i915)
+{
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = batch_create(i915, 4095)
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ };
+ struct timespec tv;
+ uint64_t elapsed;
+ int link[2];
+
+ /*
+* First low priority client create mass of holes in their
+* own address space, then launch a batch with oodles of object with
+* alignment that doesn't match previous one. While lp execbufer
+* is performing we want to start high priority task
+* and we expect it will not be blocked.
+*/
+
+ igt_require(gem_uses_full_ppgtt(i915));
+ igt_assert(pipe(link) == 0);
+
+ /* Prime our prestine context */
+ gem_execbuf(i915, );
+
+ igt_fork(child, 1)
+ naughty_child(i915, link[1]);
+
+ igt_debug("Waiting for naughty client\n");
+ read(link[0], , sizeof(tv));
+ igt_debug("Ready...\n");
+ sleep(1); /* let the naughty execbuf begin */
+ igt_debug("Go!\n");
+
+ igt_nsec_elapsed(memset(, 0, sizeof(tv)));
+ gem_execbuf(i915, );
+ elapsed = igt_nsec_elapsed();
+ igt_info("Normal client took %'"PRIu64"ns\n", elapsed);
+
+ igt_waitchildren();
+ gem_close(i915, obj.handle);
+
+ igt_assert(elapsed < 10 * 1000 * 1000); /* 10ms */
+ close(link[0]);
+ close(link[1]);
+}
+
static void many(int fd, int timeout)
{
struct drm_i915_gem_exec_object2 *execobj;
@@ -281,4 +395,6 @@ igt_main
single(fd);
igt_subtest("many")
many(fd, 20);
+ igt_subtest("pi")
+ prio_inversion(fd);
}
diff --git
Re: [Intel-gfx] [PATCH 07/11] drm/i915/gem: Try allocating va from free space
On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
>
> If the current node/entry location is occupied, and the object is not
> pinned, try assigning it some free space. We cannot wait here, so if in
> doubt, we unreserve and try to grab all at once.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index bc8aa9604787..d8c746108d85 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -446,8 +446,17 @@ eb_pin_vma(struct i915_execbuffer *eb,
> if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
> pin_flags |= PIN_GLOBAL;
>
> - if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags)))
> - return false;
> + if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags))) {
> + if (entry->flags & EXEC_OBJECT_PINNED)
> + return false;
> +
> + pin_flags &= ~PIN_OFFSET_FIXED;
> + if (unlikely(i915_vma_pin(vma,
> + entry->pad_to_size,
> + entry->alignment,
> + pin_flags)))
Just curious, why not just apply the rest of the flags here(MAP, 48B,
BIAS etc) which saves us from having to bind/unbind/bind if it's
trivially misplaced?
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/display: Move out code to return the digital_port of the aux ch
On Wed, 2020-04-01 at 15:18 +0800, You-Sheng Yang wrote:
> On 2020-04-01 08:41, José Roberto de Souza wrote:
> > Moving the code to return the digital port of the aux channel also
> > removing the intel_phy_is_tc() to make it generic.
> > digital_port will be needed in icl_tc_phy_aux_power_well_enable()
> > so adding it as a parameter to icl_tc_port_assert_ref_held().
> >
> > While at at removing the duplicated call to icl_tc_phy_aux_ch() in
> > icl_tc_port_assert_ref_held().
> >
> > Signed-off-by: José Roberto de Souza
> > ---
> > .../drm/i915/display/intel_display_power.c| 38 ++-
> >
> > 1 file changed, 21 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 433e5a81dd4d..02a07aa710e4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -500,26 +500,14 @@ static int power_well_async_ref_count(struct
> > drm_i915_private *dev_priv,
> > return refs;
> > }
> >
> > -static void icl_tc_port_assert_ref_held(struct drm_i915_private
> > *dev_priv,
> > - struct i915_power_well
> > *power_well)
> > +static struct intel_digital_port *
> > +aux_ch_to_digital_port(struct drm_i915_private *dev_priv,
> > + enum aux_ch aux_ch)
>
> This fails the build because icl_tc_port_assert_ref_held was
> originally
> guarded by CONFIG_DRM_I915_DEBUG_RUNTIME_PM, but now
> aux_ch_to_digital_port maybe used outside the scope.
Thanks, fixed.
>
> > {
> > - enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
> > struct intel_digital_port *dig_port = NULL;
> > struct intel_encoder *encoder;
> >
> > - /* Bypass the check if all references are released
> > asynchronously */
> > - if (power_well_async_ref_count(dev_priv, power_well) ==
> > - power_well->count)
> > - return;
> > -
> > - aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
> > -
> > for_each_intel_encoder(_priv->drm, encoder) {
> > - enum phy phy = intel_port_to_phy(dev_priv, encoder-
> > >port);
> > -
> > - if (!intel_phy_is_tc(dev_priv, phy))
> > - continue;
> > -
> > /* We'll check the MST primary port */
> > if (encoder->type == INTEL_OUTPUT_DP_MST)
> > continue;
> > @@ -536,6 +524,18 @@ static void icl_tc_port_assert_ref_held(struct
> > drm_i915_private *dev_priv,
> > break;
> > }
> >
> > + return dig_port;
> > +}
> > +
> > +static void icl_tc_port_assert_ref_held(struct drm_i915_private
> > *dev_priv,
> > + struct i915_power_well
> > *power_well,
> > + struct intel_digital_port
> > *dig_port)
> > +{
> > + /* Bypass the check if all references are released
> > asynchronously */
> > + if (power_well_async_ref_count(dev_priv, power_well) ==
> > + power_well->count)
> > + return;
> > +
> > if (drm_WARN_ON(_priv->drm, !dig_port))
> > return;
> >
> > @@ -558,9 +558,10 @@ icl_tc_phy_aux_power_well_enable(struct
> > drm_i915_private *dev_priv,
> > struct i915_power_well *power_well)
> > {
> > enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
> > + struct intel_digital_port *dig_port =
> > aux_ch_to_digital_port(dev_priv, aux_ch);
>
> E.g. here.
>
> > u32 val;
> >
> > - icl_tc_port_assert_ref_held(dev_priv, power_well);
> > + icl_tc_port_assert_ref_held(dev_priv, power_well, dig_port);
> >
> > val = intel_de_read(dev_priv, DP_AUX_CH_CTL(aux_ch));
> > val &= ~DP_AUX_CH_CTL_TBT_IO;
> > @@ -588,7 +589,10 @@ static void
> > icl_tc_phy_aux_power_well_disable(struct drm_i915_private
> > *dev_priv,
> > struct i915_power_well *power_well)
> > {
> > - icl_tc_port_assert_ref_held(dev_priv, power_well);
> > + enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
> > + struct intel_digital_port *dig_port =
> > aux_ch_to_digital_port(dev_priv, aux_ch);
> > +
> > + icl_tc_port_assert_ref_held(dev_priv, power_well, dig_port);
> >
> > hsw_power_well_disable(dev_priv, power_well);
> > }
> >
>
> You-Sheng Yang
>
___
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/perf: Do not clear pollin for small user read buffers (rev6)
== Series Details == Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev6) URL : https://patchwork.freedesktop.org/series/75085/ State : success == Summary == CI Bug Log - changes from CI_DRM_8230_full -> Patchwork_17166_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_8230_full and Patchwork_17166_full: ### New IGT tests (1) ### * igt@gem_exec_capture@capture: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_17166_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@implicit-read-write-bsd2: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276] / [i915#677]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-iclb5/igt@gem_exec_sched...@implicit-read-write-bsd2.html * igt@gem_exec_schedule@out-order-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-iclb4/igt@gem_exec_sched...@out-order-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-iclb3/igt@gem_exec_sched...@out-order-bsd2.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-iclb6/igt@gem_exec_sched...@pi-common-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-iclb7/igt@gem_exec_sched...@preempt-other-chain-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-kbl6/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-kbl6/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#454]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-iclb3/igt@i915_pm...@dc6-psr.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-iclb4/igt@i915_pm...@dc6-psr.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-random: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#54] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-apl3/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#300]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-skl8/igt@kms_cursor_...@pipe-b-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-skl8/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-skl: [PASS][17] -> [FAIL][18] ([IGT#5] / [i915#697]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-skl9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html * igt@kms_flip@plain-flip-ts-check-interruptible: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#34]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-skl3/igt@kms_f...@plain-flip-ts-check-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-skl5/igt@kms_f...@plain-flip-ts-check-interruptible.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-skl10/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17166/shard-skl10/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: move remaining debugfs interfaces into gt (rev2)
== Series Details == Series: drm/i915/gt: move remaining debugfs interfaces into gt (rev2) URL : https://patchwork.freedesktop.org/series/75333/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8230_full -> Patchwork_17165_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17165_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17165_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_17165_full: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@debugfs-forcewake-user: - shard-iclb: [PASS][1] -> [SKIP][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-iclb5/igt@i915_pm_...@debugfs-forcewake-user.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-iclb5/igt@i915_pm_...@debugfs-forcewake-user.html - shard-tglb: [PASS][3] -> [SKIP][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-tglb6/igt@i915_pm_...@debugfs-forcewake-user.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-tglb6/igt@i915_pm_...@debugfs-forcewake-user.html * igt@i915_suspend@forcewake: - shard-snb: [PASS][5] -> [FAIL][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-snb5/igt@i915_susp...@forcewake.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-snb5/igt@i915_susp...@forcewake.html * igt@perf_pmu@rc6: - shard-apl: [PASS][7] -> [FAIL][8] +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-apl3/igt@perf_...@rc6.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-apl7/igt@perf_...@rc6.html - shard-glk: [PASS][9] -> [FAIL][10] +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-glk3/igt@perf_...@rc6.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-glk9/igt@perf_...@rc6.html - shard-tglb: [PASS][11] -> [FAIL][12] +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-tglb5/igt@perf_...@rc6.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-tglb1/igt@perf_...@rc6.html - shard-kbl: [PASS][13] -> [FAIL][14] +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-kbl2/igt@perf_...@rc6.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-kbl2/igt@perf_...@rc6.html * igt@perf_pmu@rc6-runtime-pm: - shard-skl: [PASS][15] -> [FAIL][16] +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-skl10/igt@perf_...@rc6-runtime-pm.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-skl1/igt@perf_...@rc6-runtime-pm.html * igt@perf_pmu@rc6-runtime-pm-long: - shard-iclb: [PASS][17] -> [FAIL][18] +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-iclb7/igt@perf_...@rc6-runtime-pm-long.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-iclb4/igt@perf_...@rc6-runtime-pm-long.html New tests - New tests have been introduced between CI_DRM_8230_full and Patchwork_17165_full: ### New IGT tests (1) ### * igt@gem_exec_capture@capture: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_17165_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#110854]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-iclb4/igt@gem_exec_balan...@smoke.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@pi-userfault-bsd: - shard-iclb: [PASS][21] -> [SKIP][22] ([i915#677]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-iclb8/igt@gem_exec_sched...@pi-userfault-bsd.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-iclb2/igt@gem_exec_sched...@pi-userfault-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#112146]) +5 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8230/shard-iclb7/igt@gem_exec_sched...@preempt-other-chain-bsd.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17165/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html *
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Fill all the unused space in the GGTT (rev2)
== Series Details == Series: drm/i915/gt: Fill all the unused space in the GGTT (rev2) URL : https://patchwork.freedesktop.org/series/75320/ State : success == Summary == CI Bug Log - changes from CI_DRM_8229_full -> Patchwork_17160_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_8229_full and Patchwork_17160_full: ### New IGT tests (1) ### * igt@gem_exec_capture@capture: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_17160_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@rcs0: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-skl2/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html * igt@gem_exec_schedule@implicit-both-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +9 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-apl3/igt@gem_workarou...@suspend-resume-context.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-apl4/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-random: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#54] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-apl2/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#300]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-skl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#52] / [i915#54]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-skl10/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-untiled.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-skl7/igt@kms_draw_...@draw-method-xrgb2101010-mmap-cpu-untiled.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180] / [i915#93] / [i915#95]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-kbl6/igt@kms_frontbuffer_track...@fbc-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#899]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-glk6/igt@kms_plane_low...@pipe-a-tiling-x.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-glk4/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-iclb2/igt@kms_psr2...@frontbuffer.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-iclb6/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8229/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17160/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +3 similar issues [23]:
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: Add i915_lpsp_info debugfs
On 31-03-2020 17:07, Anshuman Gupta wrote:
New i915_pm_lpsp igt solution approach relies on connector specific
debugfs attribute i915_lpsp_info, it exposes whether an output is
capable of driving lpsp and exposes lpsp enablement info.
v2:
- CI fixup.
v3:
- register i915_lpsp_info only for supported connector. [Jani]
- use intel_display_power_well_is_enabled() instead of looking
inside power_well count. [Jani]
- fixes the lpsp capable conditional logic. [Jani]
- combined the lpsp capable and enable info. [Jani]
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_debugfs.c | 124 ++
.../drm/i915/display/intel_display_power.h| 2 +
2 files changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 424f4e52f783..b185c4617468 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -9,6 +9,7 @@
#include "i915_debugfs.h"
#include "intel_csr.h"
#include "intel_display_debugfs.h"
+#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_fbc.h"
@@ -611,6 +612,98 @@ static void intel_hdcp_info(struct seq_file *m,
seq_puts(m, "\n");
}
+#define LPSP_CAPABLE(COND) (COND ? seq_puts(m, "LPSP capable\n") : seq_puts(m, "LPSP incapable\n"))
+#define LPSP_ENABLE(COND) (COND ? seq_puts(m, "LPSP enabled\n") : seq_puts(m, "LPSP
disabled\n"))
+
+/* LVDS also an embedded panel but we are not interested in it */
+static bool intel_have_embedded_panel(struct drm_connector *connector)
+{
+ return connector->connector_type == DRM_MODE_CONNECTOR_DSI ||
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP;
+}
+
+static bool intel_have_gen9_lpsp_panel(struct drm_connector *connector)
+{
+ return intel_have_embedded_panel(connector) ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort;
+}
+
+static bool intel_have_lpsp_supported_panel(struct drm_connector *connector)
+{
+ return intel_have_gen9_lpsp_panel(connector) ||
+ connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
+ connector->connector_type == DRM_MODE_CONNECTOR_HDMIB;
+}
This function will pass for every platform for almost all (EDP/MIPI/DP/HDMI)
connector type even if not supported ...rt?
Apart from that I did not understand the purpose of above functions.
Can we have a single function to check the connector is supported lpsp or not.
static bool is_lpsp_supported(struct drm_connector *connector)
In function definition we can check for platform first, then check
connector_type and return true/false.
+
+static bool
+intel_lpsp_power_well_enabled(struct drm_i915_private *dev_priv,
+ enum i915_power_well_id power_well_id)
+{
+ intel_wakeref_t wakeref;
+ bool is_enabled;
+
+ wakeref = intel_runtime_pm_get(_priv->runtime_pm);
+ is_enabled = intel_display_power_well_is_enabled(dev_priv,
+power_well_id);
+ intel_runtime_pm_put(_priv->runtime_pm, wakeref);
+
+ return is_enabled;
+}
+
+static void
+intel_lpsp_gen12_helper(struct seq_file *m, struct drm_connector *connector)
+{
+ struct intel_encoder *encoder =
+ intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ bool lpsp_capable = false;
+
+ if (IS_TIGERLAKE(dev_priv))
+ lpsp_capable = encoder->port <= PORT_C;
+
+ LPSP_CAPABLE(lpsp_capable);
is_supported and capable looks similar to me, what is the difference?
+ LPSP_ENABLE(!intel_lpsp_power_well_enabled(dev_priv, ICL_DISP_PW_3));
+}
+
+static void
+intel_lpsp_gen11_helper(struct seq_file *m, struct drm_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ LPSP_CAPABLE(intel_have_embedded_panel(connector));
+ LPSP_ENABLE(!intel_lpsp_power_well_enabled(dev_priv, ICL_DISP_PW_3));
+}
+
+static void
+intel_lpsp_gen9_helper(struct seq_file *m, struct drm_connector *connector)
+{
+ struct intel_encoder *encoder =
+ intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ LPSP_CAPABLE(encoder->port == PORT_A &&
+intel_have_gen9_lpsp_panel(connector));
+ LPSP_ENABLE(!intel_lpsp_power_well_enabled(dev_priv, SKL_DISP_PW_2));
+}
+
+static void
+intel_lpsp_legacy_gen_helper(struct seq_file *m,
+struct drm_connector *connector)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
+ /*
+* Apart from HASWELL/BROADWELL other legacy platform doesn't
+* support lpsp.
+*/
+ if
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Report all failed registers for ctx isolation (rev2)
== Series Details ==
Series: drm/i915: Report all failed registers for ctx isolation (rev2)
URL : https://patchwork.freedesktop.org/series/75318/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17159_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17159_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb}:
- shard-glk: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-glk3/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
- shard-skl: NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
New tests
-
New tests have been introduced between CI_DRM_8228_full and
Patchwork_17159_full:
### New IGT tests (1) ###
* igt@gem_exec_capture@capture:
- Statuses :
- Exec time: [None] s
Known issues
Here are the changes found in Patchwork_17159_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@implicit-both-bsd1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [i915#677]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb2/igt@gem_exec_sched...@implicit-both-bsd1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-iclb7/igt@gem_exec_sched...@implicit-both-bsd1.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@preempt-contexts-bsd2:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +15 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb4/igt@gem_exec_sched...@preempt-contexts-bsd2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-iclb3/igt@gem_exec_sched...@preempt-contexts-bsd2.html
* igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +6 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb8/igt@gem_exec_sched...@reorder-wide-bsd.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html
* igt@i915_pm_rps@min-max-config-loaded:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#39])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-glk3/igt@i915_pm_...@min-max-config-loaded.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-glk8/igt@i915_pm_...@min-max-config-loaded.html
* igt@kms_cursor_crc@pipe-a-cursor-alpha-transparent:
- shard-skl: [PASS][13] -> [FAIL][14] ([i915#54])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-alpha-transparent.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-alpha-transparent.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +4
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109349])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-iclb8/igt@kms_dp_...@basic-dsc-enable-edp.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180] /
[i915#93] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-kbl6/igt@kms_fbcon_...@fbc-suspend.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17159/shard-kbl3/igt@kms_fbcon_...@fbc-suspend.html
* igt@kms_flip@dpms-vs-vblank-race-interruptible:
- shard-glk: [PASS][21] -> [FAIL][22] ([i915#407])
[21]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Make Wa_14010229206 permanent
== Series Details == Series: drm/i915/tgl: Make Wa_14010229206 permanent URL : https://patchwork.freedesktop.org/series/75139/ State : success == Summary == CI Bug Log - changes from CI_DRM_8197_full -> Patchwork_17107_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17107_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([i915#1492]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb4/igt@gem_ctx_persiste...@close-replace-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb2/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_eio@in-flight-suspend: - shard-glk: [PASS][3] -> [CRASH][4] ([i915#395]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-glk1/igt@gem_...@in-flight-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-glk4/igt@gem_...@in-flight-suspend.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb6/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb3/igt@gem_exec_sched...@pi-common-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#54] / [i915#93] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-64x21-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-64x21-onscreen.html * igt@kms_cursor_crc@pipe-c-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_8197/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_draw_crc@draw-method-rgb565-blt-untiled: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#52] / [i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-glk9/igt@kms_draw_...@draw-method-rgb565-blt-untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-glk7/igt@kms_draw_...@draw-method-rgb565-blt-untiled.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-skl10/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-glk6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-glk4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-apl7/igt@kms_f...@flip-vs-suspend-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-apl8/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#1188]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-skl9/igt@kms_...@bpc-switch-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-skl10/igt@kms_...@bpc-switch-suspend.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Include a few tracek for timeslicing
== Series Details ==
Series: drm/i915/gt: Include a few tracek for timeslicing
URL : https://patchwork.freedesktop.org/series/75317/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17158_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17158_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17158_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_17158_full:
### IGT changes ###
Possible regressions
* igt@gem_mmap_gtt@big-copy-odd:
- shard-kbl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-kbl2/igt@gem_mmap_...@big-copy-odd.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-kbl6/igt@gem_mmap_...@big-copy-odd.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb}:
- shard-glk: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-glk3/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
- shard-skl: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
New tests
-
New tests have been introduced between CI_DRM_8228_full and
Patchwork_17158_full:
### New IGT tests (1) ###
* igt@gem_exec_capture@capture:
- Statuses :
- Exec time: [None] s
Known issues
Here are the changes found in Patchwork_17158_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112080]) +6 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb1/igt@gem_b...@busy-vcs1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-iclb6/igt@gem_b...@busy-vcs1.html
* igt@gem_exec_schedule@implicit-write-read-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb8/igt@gem_exec_sched...@implicit-write-read-bsd.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-iclb4/igt@gem_exec_sched...@implicit-write-read-bsd.html
* igt@gem_exec_schedule@smoketest-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb3/igt@gem_exec_sched...@smoketest-bsd.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-iclb4/igt@gem_exec_sched...@smoketest-bsd.html
* igt@i915_suspend@forcewake:
- shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +5
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-kbl7/igt@i915_susp...@forcewake.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-kbl2/igt@i915_susp...@forcewake.html
* igt@kms_cursor_crc@pipe-a-cursor-alpha-transparent:
- shard-skl: [PASS][13] -> [FAIL][14] ([i915#54])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-alpha-transparent.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-skl2/igt@kms_cursor_...@pipe-a-cursor-alpha-transparent.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109349])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-iclb7/igt@kms_dp_...@basic-dsc-enable-edp.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) +1 similar
issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
* igt@kms_psr@psr2_sprite_mmap_cpu:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17158/shard-iclb7/igt@kms_psr@psr2_sprite_mmap_cpu.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-apl:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Defer kicking the tasklet until all rescheduling is complete
== Series Details ==
Series: drm/i915: Defer kicking the tasklet until all rescheduling is complete
URL : https://patchwork.freedesktop.org/series/75314/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17157_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17157_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17157_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_17157_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_persistence@engines-mixed-process@bcs0:
- shard-tglb: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-tglb8/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17157/shard-tglb8/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb}:
- shard-glk: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17157/shard-glk8/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
- shard-skl: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17157/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
New tests
-
New tests have been introduced between CI_DRM_8228_full and
Patchwork_17157_full:
### New IGT tests (1) ###
* igt@gem_exec_capture@capture:
- Statuses :
- Exec time: [None] s
Known issues
Here are the changes found in Patchwork_17157_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox:
- shard-skl: [PASS][5] -> [FAIL][6] ([i915#1528])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17157/shard-skl9/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
* igt@gem_exec_schedule@implicit-both-bsd1:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb2/igt@gem_exec_sched...@implicit-both-bsd1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17157/shard-iclb3/igt@gem_exec_sched...@implicit-both-bsd1.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) +3 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17157/shard-iclb2/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@preempt-contexts-bsd2:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +13 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb4/igt@gem_exec_sched...@preempt-contexts-bsd2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17157/shard-iclb6/igt@gem_exec_sched...@preempt-contexts-bsd2.html
* igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +7 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb8/igt@gem_exec_sched...@reorder-wide-bsd.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17157/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html
* igt@gen9_exec_parse@allowed-single:
- shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#716])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-skl6/igt@gen9_exec_pa...@allowed-single.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17157/shard-skl2/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-snb: [PASS][17] -> [TIMEOUT][18] ([i915#1526])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-snb6/igt@i915_pm_rc6_reside...@rc6-idle.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17157/shard-snb2/igt@i915_pm_rc6_reside...@rc6-idle.html
* igt@kms_cursor_crc@pipe-a-cursor-alpha-transparent:
- shard-skl: [PASS][19] -> [FAIL][20] ([i915#54])
[19]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915 lpsp support for lpsp igt (rev6)
== Series Details ==
Series: i915 lpsp support for lpsp igt (rev6)
URL : https://patchwork.freedesktop.org/series/74648/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17155_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17155_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17155_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_17155_full:
### IGT changes ###
Possible regressions
* {igt@i915_pm_lpsp@non-edp-lpsp} (NEW):
- shard-tglb: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-tglb1/igt@i915_pm_l...@non-edp-lpsp.html
- shard-iclb: NOTRUN -> [SKIP][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb6/igt@i915_pm_l...@non-edp-lpsp.html
* igt@i915_pm_rpm@fences-dpms:
- shard-tglb: [PASS][3] -> [SKIP][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-tglb6/igt@i915_pm_...@fences-dpms.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-tglb6/igt@i915_pm_...@fences-dpms.html
* igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- shard-iclb: [PASS][5] -> [SKIP][6] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb3/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb7/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html
* igt@runner@aborted:
- shard-tglb: NOTRUN -> [FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-tglb1/igt@run...@aborted.html
Warnings
* igt@i915_pm_lpsp@screens-disabled:
- shard-snb: [SKIP][8] ([fdo#109271]) -> [FAIL][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-snb2/igt@i915_pm_l...@screens-disabled.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-snb4/igt@i915_pm_l...@screens-disabled.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb}:
- shard-glk: NOTRUN -> [FAIL][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-glk7/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
- shard-skl: NOTRUN -> [FAIL][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-alpha-transparent-fb.html
New tests
-
New tests have been introduced between CI_DRM_8228_full and
Patchwork_17155_full:
### New IGT tests (2) ###
* igt@gem_exec_capture@capture:
- Statuses :
- Exec time: [None] s
* igt@i915_pm_lpsp@non-edp-lpsp:
- Statuses : 4 pass(s) 3 skip(s)
- Exec time: [0.0, 0.77] s
Known issues
Here are the changes found in Patchwork_17155_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#112080]) +8 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb1/igt@gem_b...@busy-vcs1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb6/igt@gem_b...@busy-vcs1.html
* igt@gem_exec_schedule@implicit-both-bsd1:
- shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#109276] / [i915#677])
+1 similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb2/igt@gem_exec_sched...@implicit-both-bsd1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd1.html
* igt@gem_exec_schedule@in-order-bsd2:
- shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#109276]) +10 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb2/igt@gem_exec_sched...@in-order-bsd2.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb8/igt@gem_exec_sched...@in-order-bsd2.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][18] -> [SKIP][19] ([i915#677]) +1 similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8228/shard-iclb8/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17155/shard-iclb1/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@preempt-bsd:
- shard-iclb: [PASS][20] ->
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Check for bonding support before exercising
On 31/03/2020 11:36, Chris Wilson wrote:
Don't bother trying and failing to test bonding if the kernel doesn't
even support it.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
tests/i915/gem_exec_balancer.c | 34 +++---
1 file changed, 27 insertions(+), 7 deletions(-)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index da8aff6de..9930e394d 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1936,6 +1936,22 @@ static bool has_load_balancer(int i915)
return err == 0;
}
+static bool has_bonding(int i915)
+{
+ I915_DEFINE_CONTEXT_ENGINES_BOND(bonds, 0) = {
+ .base.name = I915_CONTEXT_ENGINES_EXT_BOND,
+ };
Doh why do we allow zero bonds.. to make for an easier probe of course! :))
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
+ struct i915_engine_class_instance ci = {};
+ uint32_t ctx;
+ int err;
+
+ ctx = gem_context_create(i915);
+ err = __set_load_balancer(i915, ctx, , 1, );
+ gem_context_destroy(i915, ctx);
+
+ return err == 0;
+}
+
igt_main
{
int i915 = -1;
@@ -1992,11 +2008,18 @@ igt_main
igt_subtest("smoke")
smoketest(i915, 20);
- igt_subtest("bonded-imm")
- bonded(i915, 0);
+ igt_subtest_group {
+ igt_fixture igt_require(has_bonding(i915));
+
+ igt_subtest("bonded-imm")
+ bonded(i915, 0);
+
+ igt_subtest("bonded-cork")
+ bonded(i915, CORK);
- igt_subtest("bonded-cork")
- bonded(i915, CORK);
+ igt_subtest("bonded-early")
+ bonded_early(i915);
+ }
igt_subtest("bonded-slice")
bonded_slice(i915);
@@ -2007,9 +2030,6 @@ igt_main
igt_subtest("bonded-semaphore")
bonded_semaphore(i915);
- igt_subtest("bonded-early")
- bonded_early(i915);
-
igt_fixture {
igt_stop_hang_detector();
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Kernel 5.2 to current: possible i915 related problems
Jani Nikula writes: > On Mon, 30 Mar 2020, Dirk Gouders wrote: >> Dirk Gouders writes: >> >>> Some additional information: >>> >>> I tried to get more information by using netconsole with kernel >>> 5.6.0-rc7+. After some time, the system stopped to respond and I >>> checked the messages sent to the remote machine. Unfortunately they >>> gave no other information than the local logfile. >>> >>> Dirk >>> >>> Dirk Gouders writes: >>> Hello, because of the current pandemic situation the usage of my laptop has changed. It is now running at home 24/7 with a monitor attached to it and after about 12 days running a somewhat older kernel (5.2), it stopped working. After a reboot I found some information in the syslog that I attach to this mail. The next hang happened one day later but without any information. With a current 5.6.0-rc7+ I seem to get more frequent hangs but without any information in the log file and somewhat non-reproducable. Today, I experienced two hangs when starting xterms or other programs but after this (and necessary reboots) I am unable to reproduce a hang. Perhaps, someone has suggestion for me how to produce debugging information that survives the hangs and reboots. >> >> This time, I have some information from a hang with the current kernel >> 5.6.0-rc7+ that obviously could be written to the logfile while the >> system was starting to get problems. A minute later or so, it >> completely stopped to respond and a hard reset was necessary: >> >> Mar 30 10:37:52 lena kernel: i915 :00:02.0: GPU HANG: ecode >> 8:1:85d9, in X [4278] >> Mar 30 10:37:52 lena kernel: GPU hangs can indicate a bug anywhere in the >> entire gfx stack, including userspace. >> Mar 30 10:37:52 lena kernel: Please file a _new_ bug report at >> https://gitlab.freedesktop.org/drm/intel/issues/new. >> Mar 30 10:37:52 lena kernel: Please see > https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs > for details. >> Mar 30 10:37:52 lena kernel: drm/i915 developers can then reassign to the >> right component if it's not a kernel issue. >> Mar 30 10:37:52 lena kernel: The GPU crash dump is required to analyze GPU >> hangs, so please always attach it. >> Mar 30 10:37:52 lena kernel: GPU crash dump saved to >> /sys/class/drm/card0/error >> Mar 30 10:37:52 lena kernel: i915 :00:02.0: Resetting rcs0 for stopped >> heartbeat on rcs0 >> Mar 30 10:37:52 lena kernel: i915 :00:02.0: X[4278] context reset due to >> GPU hang >> >> Adding the i915 maintainers because I doubt the data in >> /sys/class/drm/card0/error is useful after a reboot. Should I file a >> bug report as suggested above, anyway? > > Please do. OK. I was able to reproduce GPU hangs and thus try to bisect that problem: https://gitlab.freedesktop.org/drm/intel/-/issues/1585 Dirk > BR, > Jani. > > >> >> Dirk >> Mar 27 19:36:51 lena kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Mar 27 21:45:19 lena kernel: usb 1-1: USB disconnect, device number 15 Mar 27 21:45:19 lena kernel: sd 2:0:0:0: [sdb] Synchronizing SCSI cache Mar 27 21:45:19 lena kernel: sd 2:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK Mar 27 22:00:53 lena kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Mar 27 23:46:13 lena kernel: [ cut here ] Mar 27 23:46:13 lena kernel: vblank wait timed out on crtc 1 Mar 27 23:46:13 lena kernel: WARNING: CPU: 0 PID: 4221 at drm_wait_one_vblank+0xfa/0x12a [drm] Mar 27 23:46:13 lena kernel: Modules linked in: usblp uas usb_storage uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_hda_codec _hdmi snd_hda_codec_realtek snd_hda_codec_generic crc32_pclmul crc32c_intel ghash_clmulni_intel i915 aesni_intel drm_kms_helper cfbfillrect crypto_simd glue_he lper syscopyarea cfbimgblt sysfillrect sysimgblt snd_hda_intel fb_sys_fops cfbcopyarea snd_hda_codec sdhci_acpi drm xhci_pci snd_hwdep sdhci drm_panel_orientat ion_quirks snd_hda_core intel_gtt mmc_core xhci_hcd iosf_mbi Mar 27 23:46:13 lena kernel: CPU: 0 PID: 4221 Comm: X Not tainted 5.2.0+ #44 Mar 27 23:46:13 lena kernel: Hardware name: Acer Aspire ES1-131/Garp_BA, BIOS V1.23 06/22/2016 Mar 27 23:46:13 lena kernel: RIP: 0010:drm_wait_one_vblank+0xfa/0x12a [drm] Mar 27 23:46:13 lena kernel: Code: 89 e7 e8 31 eb 74 e1 49 89 c4 eb bf 48 89 e6 4c 89 f7 e8 d5 b5 ff e0 45 85 e4 75 10 89 de 48 c7 c7 cf de 0d a0 e8 2e bd fc e 0 <0f> 0b 89 de 48 89 ef e8 82 fe ff ff 48 8b 44 24 28 65 48 33 04 25 Mar 27 23:46:13 lena kernel: RSP: 0018:c9e73ac0 EFLAGS:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Align engine dump active/pending
== Series Details == Series: drm/i915/gt: Align engine dump active/pending URL : https://patchwork.freedesktop.org/series/75363/ State : success == Summary == CI Bug Log - changes from CI_DRM_8232 -> Patchwork_17169 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17169/index.html Known issues Here are the changes found in Patchwork_17169 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_module_load@reload: - fi-skl-6770hq: [DMESG-WARN][1] ([i915#203]) -> [PASS][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8232/fi-skl-6770hq/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17169/fi-skl-6770hq/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-skl-6770hq: [SKIP][3] ([fdo#109271]) -> [PASS][4] +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8232/fi-skl-6770hq/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17169/fi-skl-6770hq/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@requests: - fi-icl-guc: [INCOMPLETE][5] ([i915#1505] / [i915#1581]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8232/fi-icl-guc/igt@i915_selftest@l...@requests.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17169/fi-icl-guc/igt@i915_selftest@l...@requests.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-skl-6770hq: [DMESG-FAIL][7] ([i915#165]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8232/fi-skl-6770hq/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17169/fi-skl-6770hq/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1505]: https://gitlab.freedesktop.org/drm/intel/issues/1505 [i915#1581]: https://gitlab.freedesktop.org/drm/intel/issues/1581 [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203 Participating hosts (49 -> 36) -- Missing(13): fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u fi-hsw-peppy fi-glk-dsi fi-byt-squawks fi-bsw-cyan fi-snb-2520m fi-kbl-7500u fi-ctg-p8600 fi-gdg-551 fi-bdw-samus fi-snb-2600 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8232 -> Patchwork_17169 CI-20190529: 20190529 CI_DRM_8232: cade363a69762c57ffb58f91b47670df7ca520bf @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5553: 60475d9b41c58b7d256e83c7d53eaf7c2f1f8ecc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17169: a8418e5a61084fde9a451c49a9351ef9df9039fa @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a8418e5a6108 drm/i915/gt: Align engine dump active/pending == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17169/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Dynamic engine tests
Use igt_subtest_with_dynamic for the flexible approach to engine
dependent test discovery.
Signed-off-by: Chris Wilson
---
lib/i915/gem_engine_topology.h | 6 +-
tests/i915/gem_exec_schedule.c | 432 -
2 files changed, 207 insertions(+), 231 deletions(-)
diff --git a/lib/i915/gem_engine_topology.h b/lib/i915/gem_engine_topology.h
index 9588f74d4..f5edcb5d1 100644
--- a/lib/i915/gem_engine_topology.h
+++ b/lib/i915/gem_engine_topology.h
@@ -68,9 +68,9 @@ struct intel_execution_engine2
gem_eb_flags_to_engine(unsigned int flags);
/* needs to replace "for_each_physical_engine" when conflicts are fixed */
#define for_each_physical_engine(fd__, ctx__, e__) \
- for (struct intel_engine_data i__ = intel_init_engine_list(fd__,
ctx__); \
-((e__) = intel_get_current_physical_engine(__)); \
-intel_next_engine(__))
+ for (struct intel_engine_data i__##e__ = intel_init_engine_list(fd__,
ctx__); \
+((e__) = intel_get_current_physical_engine(__##e__)); \
+intel_next_engine(__##e__))
#define __for_each_physical_engine(fd__, e__) \
for_each_physical_engine(fd__, 0, e__)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 2a74f13dc..7274ffbf3 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -49,15 +49,9 @@
#define MAX_PRIO LOCAL_I915_CONTEXT_MAX_USER_PRIORITY
#define MIN_PRIO LOCAL_I915_CONTEXT_MIN_USER_PRIORITY
-#define MAX_ELSP_QLEN 16
-
-#define MAX_ENGINES 16
-
#define MAX_CONTEXTS 1024
-
-#define LOCAL_I915_EXEC_BSD_SHIFT (13)
-#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
-#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
+#define MAX_ELSP_QLEN 16
+#define MAX_ENGINES (I915_EXEC_RING_MASK + 1)
#define MI_SEMAPHORE_WAIT (0x1c << 23)
#define MI_SEMAPHORE_POLL (1 << 15)
@@ -179,7 +173,7 @@ static void store_dword_fenced(int fd, uint32_t ctx,
unsigned ring,
static uint32_t create_highest_priority(int fd)
{
- uint32_t ctx = gem_context_create(fd);
+ uint32_t ctx = gem_context_clone_with_engines(fd, 0);
/*
* If there is no priority support, all contexts will have equal
@@ -248,6 +242,7 @@ enum implicit_dir {
static void implicit_rw(int i915, unsigned ring, enum implicit_dir dir)
{
+ const struct intel_execution_engine2 *e;
IGT_CORK_FENCE(cork);
unsigned int count;
uint32_t scratch;
@@ -255,8 +250,8 @@ static void implicit_rw(int i915, unsigned ring, enum
implicit_dir dir)
int fence;
count = 0;
- for_each_physical_engine(other, i915) {
- if (eb_ring(other) == ring)
+ __for_each_physical_engine(i915, e) {
+ if (e->flags == ring)
continue;
count++;
@@ -268,15 +263,15 @@ static void implicit_rw(int i915, unsigned ring, enum
implicit_dir dir)
if (dir & WRITE_READ)
store_dword_fenced(i915, 0,
- ring, scratch, 0, -ring,
+ ring, scratch, 0, ~ring,
fence, I915_GEM_DOMAIN_RENDER);
- for_each_physical_engine(other, i915) {
- if (eb_ring(other) == ring)
+ __for_each_physical_engine(i915, e) {
+ if (e->flags == ring)
continue;
store_dword_fenced(i915, 0,
- eb_ring(other), scratch, 0, eb_ring(other),
+ e->flags, scratch, 0, e->flags,
fence, 0);
}
@@ -292,21 +287,20 @@ static void implicit_rw(int i915, unsigned ring, enum
implicit_dir dir)
gem_close(i915, scratch);
if (dir & WRITE_READ)
- igt_assert_neq_u32(result, -ring);
+ igt_assert_neq_u32(result, ~ring);
if (dir & READ_WRITE)
igt_assert_eq_u32(result, ring);
}
static void independent(int fd, unsigned int engine)
{
+ const struct intel_execution_engine2 *e;
IGT_CORK_FENCE(cork);
igt_spin_t *spin = NULL;
uint32_t scratch, batch;
uint32_t *ptr;
int fence;
- igt_require(engine != 0);
-
scratch = gem_create(fd, 4096);
ptr = gem_mmap__device_coherent(fd, scratch, 0, 4096, PROT_READ);
igt_assert_eq(ptr[0], 0);
@@ -314,25 +308,25 @@ static void independent(int fd, unsigned int engine)
fence = igt_cork_plug(, fd);
/* Check that we can submit to engine while all others are blocked */
- for_each_physical_engine(e, fd) {
- if (eb_ring(e) == engine)
+ __for_each_physical_engine(fd, e) {
+ if (e->flags == engine)
continue;
- if (!gem_can_store_dword(fd, eb_ring(e)))
+ if
Re: [Intel-gfx] [PATCH 1/5] drm: report dp downstream port type as a subconnector property
On Wed, Apr 01, 2020 at 05:42:24PM +0530, Jeevan B wrote:
> Currently, downstream port type is only reported in debugfs. This
> information should be considered important since it reflects the actual
> physical connector type. Some userspace (e.g. window compositors)
> may want to show this info to a user.
>
> The 'subconnector' property is already utilized for DVI-I and TV-out for
> reporting connector subtype.
>
> The initial motivation for this feature came from i2c test [1].
> It is supposed to be skipped on VGA connectors, but it cannot
> detect VGA over DP and fails instead.
>
> v2:
> - Ville: utilized drm_dp_is_branch()
> - Ville: implement DP 1.0 downstream type info
> - Replaced create_dp_properties with add_dp_subconnector_property
> - Added dp_set_subconnector_property helper
>
> v4:
> - Ville: add DP1.0 best assumption about subconnector
> - Ville: assume DVI is DVI-D
> - Ville: reuse Writeback enum value for Virtual subconnector
> - Renamed #defines: HDMI -> HDMIA, DP -> DisplayPort
>
> [1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097
>
> Reviewed-by: Emil Velikov
> Signed-off-by: Oleg Vasilev
Is this Oleg's patch? If so why did you change the patch author to be
yourself?
> Cc: Ville Syrjälä
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Jeevan B
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190829114854.1539-3-oleg.vasi...@intel.com
> ---
> drivers/gpu/drm/drm_connector.c | 49 --
> drivers/gpu/drm/drm_dp_helper.c | 77
> +
> include/drm/drm_connector.h | 3 ++
> include/drm/drm_dp_helper.h | 8 +
> include/drm/drm_mode_config.h | 6
> include/uapi/drm/drm_mode.h | 21 ++-
> 6 files changed, 154 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b1099e1..b6972d1 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -844,7 +844,7 @@ static const struct drm_prop_enum_list
> drm_dvi_i_select_enum_list[] = {
> DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
>
> static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] = {
> - { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
> + { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-out and
> DP */
> { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> { DRM_MODE_SUBCONNECTOR_DVIA, "DVI-A" }, /* DVI-I */
> };
> @@ -861,7 +861,7 @@ static const struct drm_prop_enum_list
> drm_tv_select_enum_list[] = {
> DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
>
> static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] = {
> - { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
> + { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-out and
> DP */
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> { DRM_MODE_SUBCONNECTOR_SVIDEO,"SVIDEO"}, /* TV-out */
> { DRM_MODE_SUBCONNECTOR_Component, "Component" }, /* TV-out */
> @@ -870,6 +870,19 @@ static const struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] = {
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>
> +static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
> + { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-out
> and DP */
> + { DRM_MODE_SUBCONNECTOR_VGA, "VGA" }, /* DP */
> + { DRM_MODE_SUBCONNECTOR_DVID,"DVI-D" }, /* DP */
> + { DRM_MODE_SUBCONNECTOR_HDMIA, "HDMI" }, /* DP */
> + { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
> + { DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
> + { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
> +};
> +
> +DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
> + drm_dp_subconnector_enum_list)
> +
> static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> /* For Default case, driver will set the colorspace */
> { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
> @@ -1186,6 +1199,14 @@ static const struct drm_prop_enum_list
> dp_colorspaces[] = {
> * can also expose this property to external outputs, in which case they
> * must support "None", which should be the default (since external screens
> * have a built-in scaler).
> + *
> + * subconnector:
> + * This property is used by DVI-I, TVout and DisplayPort to indicate
> different
> + * connector subtypes. Enum values more or less match with those from main
> + * connector types.
> + * For DVI-I and TVout there is also a matching property "select
> subconnector"
> + * allowing to switch between signal types.
> + * DP subconnector corresponds to a downstream port.
> */
>
>
Re: [Intel-gfx] [PATCH 6/6] drm/i915/tc/tgl: Implement TC cold sequences
On Tue, Mar 31, 2020 at 05:41:20PM -0700, José Roberto de Souza wrote:
> TC ports can enter in TCCOLD to save power and is required to request
> to PCODE to exit this state before use or read to TC registers.
>
> For TGL there is a new MBOX command to do that with a parameter to ask
> PCODE to exit and block TCCOLD entry or unblock TCCOLD entry.
>
> So adding a new power domain to reuse the refcount and only allow
> TC cold when all TC ports are not in use.
>
> BSpec: 49294
> Cc: Imre Deak
> Cc: Cooper Chiou
> Cc: Kai-Heng Feng
> Signed-off-by: José Roberto de Souza
> ---
> .../drm/i915/display/intel_display_power.c| 46 ++
> .../drm/i915/display/intel_display_power.h| 1 +
> drivers/gpu/drm/i915/display/intel_tc.c | 63 +++
> drivers/gpu/drm/i915/display/intel_tc.h | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 3 +
> 5 files changed, 103 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 1ccd57d645c7..5de115583146 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -2842,6 +2842,8 @@ void intel_display_power_put(struct drm_i915_private
> *dev_priv,
> #define TGL_AUX_I_TBT6_IO_POWER_DOMAINS (\
> BIT_ULL(POWER_DOMAIN_AUX_I_TBT))
>
> +#define TGL_TC_COLD_OFF (BIT_ULL(POWER_DOMAIN_TC_COLD_OFF))
TGL_TC_COLD_OFF_POWER_DOMAINS
and should also include all the AUX power domains.
> +
> static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
> .sync_hw = i9xx_power_well_sync_hw_noop,
> .enable = i9xx_always_on_power_well_noop,
> @@ -3944,6 +3946,44 @@ static const struct i915_power_well_desc
> ehl_power_wells[] = {
> },
> };
>
> +static void
> +tgl_tc_cold_off_power_well_enable(struct drm_i915_private *i915,
> + struct i915_power_well *power_well)
> +{
> + intel_tc_tgl_tc_cold_request(i915, true);
> +}
> +
> +static void
> +tgl_tc_cold_off_power_well_disable(struct drm_i915_private *i915,
> +struct i915_power_well *power_well)
> +{
> + intel_tc_tgl_tc_cold_request(i915, false);
> +}
> +
> +static void
> +tgl_tc_cold_off_power_well_sync_hw(struct drm_i915_private *i915,
> +struct i915_power_well *power_well)
> +{
> + if (power_well->count > 0)
> + tgl_tc_cold_off_power_well_enable(i915, power_well);
> + else
> + tgl_tc_cold_off_power_well_disable(i915, power_well);
> +}
> +
> +static bool tgl_tc_cold_off_power_well_is_enabled(struct drm_i915_private
> *dev_priv,
> + struct i915_power_well
> *power_well)
> +{
> + /* There is no way to just read it from PCODE */
> + return false;
> +}
> +
> +static const struct i915_power_well_ops tgl_tc_cold_off_ops = {
> + .sync_hw = tgl_tc_cold_off_power_well_sync_hw,
> + .enable = tgl_tc_cold_off_power_well_enable,
> + .disable = tgl_tc_cold_off_power_well_disable,
> + .is_enabled = tgl_tc_cold_off_power_well_is_enabled,
> +};
> +
> static const struct i915_power_well_desc tgl_power_wells[] = {
> {
> .name = "always-on",
> @@ -4271,6 +4311,12 @@ static const struct i915_power_well_desc
> tgl_power_wells[] = {
> .hsw.irq_pipe_mask = BIT(PIPE_D),
> },
> },
> + {
> + .name = "TC cold off",
> + .domains = POWER_DOMAIN_TC_COLD_OFF,
TGL_TC_COLD_OFF_POWER_DOMAINS
> + .ops = _tc_cold_off_ops,
> + .id = DISP_PW_ID_NONE,
> + },
> };
>
> static int
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> b/drivers/gpu/drm/i915/display/intel_display_power.h
> index da64a5edae7a..070457e7b948 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> @@ -76,6 +76,7 @@ enum intel_display_power_domain {
> POWER_DOMAIN_MODESET,
> POWER_DOMAIN_GT_IRQ,
> POWER_DOMAIN_DPLL_DC_OFF,
> + POWER_DOMAIN_TC_COLD_OFF,
> POWER_DOMAIN_INIT,
>
> POWER_DOMAIN_NUM,
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index b6d67f069ef7..58f19037411a 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -507,11 +507,16 @@ static void __intel_tc_port_lock(struct
> intel_digital_port *dig_port,
>
> mutex_lock(_port->tc_lock);
>
> - if (INTEL_GEN(i915) == 11 && dig_port->tc_link_refcount == 0) {
> - enum intel_display_power_domain aux_domain;
> + if (dig_port->tc_link_refcount == 0) {
> + enum intel_display_power_domain domain;
>
> - aux_domain = intel_aux_ch_to_power_domain(dig_port->aux_ch);
> -
Re: [Intel-gfx] [PATCH 5/6] drm/i915/tc/icl: Implement TC cold sequences
On Tue, Mar 31, 2020 at 05:41:19PM -0700, José Roberto de Souza wrote:
> This is required for legacy/static TC ports as IOM is not aware of
> the connection and will not trigger the TC cold exit.
>
> Just request PCODE to exit TCCOLD is not enough as it could enter
> again be driver makes use of the port, to prevent it BSpec states that
> aux powerwell should be held.
>
> So here embedding the TC cold exit sequence into ICL aux enable,
> it will enable aux, request tc cold exit and depending in the TC live
> state continue with the regular aux enable sequence.
>
> And then turning on aux power well during tc lock and turning off
> during unlock both depending into the TC port refcount.
>
> BSpec: 21750
> Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1296
> Cc: Imre Deak
> Cc: Cooper Chiou
> Cc: Kai-Heng Feng
> Signed-off-by: José Roberto de Souza
> ---
>
> Will run some tests in the office with TBT dockstation to check if
> it will be a issue keep both aux enabled. Otherwise more changes will
> be required here.
>
> .../drm/i915/display/intel_display_power.c| 12 -
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_tc.c | 47 ++-
> drivers/gpu/drm/i915/display/intel_tc.h | 2 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 5 files changed, 59 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index dbd61517ba63..1ccd57d645c7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -592,9 +592,17 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private
> *dev_priv,
>
> _hsw_power_well_enable(dev_priv, power_well);
>
> - /* TODO ICL TC cold handling */
> + if (INTEL_GEN(dev_priv) == 11)
Should be if (ICL && dig_port->tc_legacy_port)
> + intel_tc_icl_tc_cold_exit(dev_priv);
>
> - _hsw_power_well_continue_enable(dev_priv, power_well);
> + /*
> + * To avoid power well enable timeouts when disconnected or in TBT mode
> + * when doing the TC cold exit sequence for GEN11
> + */
> + if (INTEL_GEN(dev_priv) != 11 ||
> + (intel_tc_port_live_status_mask(dig_port) &
> + (TC_PORT_LEGACY | TC_PORT_DP_ALT)))
> + _hsw_power_well_continue_enable(dev_priv, power_well);
Why can't we call this unconditionally?
>
> if (INTEL_GEN(dev_priv) >= 12 && !power_well->desc->hsw.is_tc_tbt) {
> enum tc_port tc_port;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 176ab5f1e867..a9a4a3c1b4d7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1391,6 +1391,7 @@ struct intel_digital_port {
> enum intel_display_power_domain ddi_io_power_domain;
> struct mutex tc_lock; /* protects the TypeC port mode */
> intel_wakeref_t tc_lock_wakeref;
> + intel_wakeref_t tc_cold_wakeref;
> int tc_link_refcount;
> bool tc_legacy_port:1;
> char tc_port_name[8];
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index d944be935423..b6d67f069ef7 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -7,6 +7,7 @@
> #include "intel_display.h"
> #include "intel_display_types.h"
> #include "intel_dp_mst.h"
> +#include "intel_sideband.h"
> #include "intel_tc.h"
>
> static const char *tc_port_mode_name(enum tc_port_mode mode)
> @@ -506,6 +507,13 @@ static void __intel_tc_port_lock(struct
> intel_digital_port *dig_port,
>
> mutex_lock(_port->tc_lock);
>
> + if (INTEL_GEN(i915) == 11 && dig_port->tc_link_refcount == 0) {
> + enum intel_display_power_domain aux_domain;
> +
> + aux_domain = intel_aux_ch_to_power_domain(dig_port->aux_ch);
> + dig_port->tc_cold_wakeref = intel_display_power_get(i915,
> aux_domain);
> + }
> +
It would be enough to hold this ref only for the time we access FIA
regs. Anything else later will hold its own AUX reference, which takes
care of blocking tc-cold. So here something like:
tc_cold_wakeref = block_tc_cold(dig_port);
where block_tc_cold() would return a non-NULL wakeref only for
ICL/dig_port->tc_legacy_port and TGL.
> if (!dig_port->tc_link_refcount &&
> intel_tc_port_needs_reset(dig_port))
> intel_tc_port_reset_mode(dig_port, required_lanes);
unblock_tc_cold(tc_cold_wakeref);
We need to call block/unblock_tc_cold() also in intel_tc_port_sanitize()
and intel_tc_port_connected().
> @@ -519,15 +527,30 @@ void intel_tc_port_lock(struct intel_digital_port
> *dig_port)
> __intel_tc_port_lock(dig_port, 1);
> }
>
>
Re: [Intel-gfx] [PATCH 1/5] drm: report dp downstream port type as a subconnector property
>
> > -Original Message-
> > From: B, Jeevan
> > Sent: Wednesday, April 1, 2020 5:42 PM
> > To: Shankar, Uma
> > Cc: B, Jeevan ; Ville Syrjälä
> > ; intel-gfx@lists.freedesktop.org
> > Subject: [PATCH 1/5] drm: report dp downstream port type as a
> > subconnector property
> >
> > Currently, downstream port type is only reported in debugfs. This
> > information should be considered important since it reflects the
> > actual physical connector type. Some userspace (e.g. window compositors) may
> want to show this info to a user.
> >
> > The 'subconnector' property is already utilized for DVI-I and TV-out
> > for reporting connector subtype.
> >
> > The initial motivation for this feature came from i2c test [1].
> > It is supposed to be skipped on VGA connectors, but it cannot detect
> > VGA over DP and fails instead.
> >
> > v2:
> > - Ville: utilized drm_dp_is_branch()
> > - Ville: implement DP 1.0 downstream type info
> > - Replaced create_dp_properties with add_dp_subconnector_property
> > - Added dp_set_subconnector_property helper
> >
> > v4:
> > - Ville: add DP1.0 best assumption about subconnector
> > - Ville: assume DVI is DVI-D
> > - Ville: reuse Writeback enum value for Virtual subconnector
> > - Renamed #defines: HDMI -> HDMIA, DP -> DisplayPort
> >
> > [1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097
> >
> > Reviewed-by: Emil Velikov
> > Signed-off-by: Oleg Vasilev
> > Cc: Ville Syrjälä
> > Cc: intel-gfx@lists.freedesktop.org
> > Signed-off-by: Jeevan B
>
> You can update the version number for this series : use subject-prefix=v5 as
> git-
> format.
> Also move your signed off close to Oleg's. Best is to put Cc: at the top,
> then all
> Signed-off and Reviewed-by
>
> Also in patch mention change in v5, like if it's just rebased
> V5: rebase
Also, please send the series to intel-gfx as well as dri-devel for review.
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20190829114854.1539-3-
> > oleg.vasi...@intel.com
> > ---
> > drivers/gpu/drm/drm_connector.c | 49 --
> > drivers/gpu/drm/drm_dp_helper.c | 77
> > +
> > include/drm/drm_connector.h | 3 ++
> > include/drm/drm_dp_helper.h | 8 +
> > include/drm/drm_mode_config.h | 6
> > include/uapi/drm/drm_mode.h | 21 ++-
> > 6 files changed, 154 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c index b1099e1..b6972d1 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -844,7 +844,7 @@ static const struct drm_prop_enum_list
> > drm_dvi_i_select_enum_list[] = {
> > DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name,
> > drm_dvi_i_select_enum_list)
> >
> > static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[]
> > = {
> > - { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and
> > TV-out */
> > + { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-
> > out and DP */
> > { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> > { DRM_MODE_SUBCONNECTOR_DVIA, "DVI-A" }, /* DVI-I */
> > };
> > @@ -861,7 +861,7 @@ static const struct drm_prop_enum_list
> > drm_tv_select_enum_list[] = {
> > DRM_ENUM_NAME_FN(drm_get_tv_select_name,
> > drm_tv_select_enum_list)
> >
> > static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] = {
> > - { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and
> > TV-out */
> > + { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-
> > out and DP */
> > { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> > { DRM_MODE_SUBCONNECTOR_SVIDEO,"SVIDEO"}, /* TV-out */
> > { DRM_MODE_SUBCONNECTOR_Component, "Component" }, /* TV-out */
> @@
> > -870,6 +870,19 @@ static const struct drm_prop_enum_list
> > drm_tv_subconnector_enum_list[] = {
> > DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
> > drm_tv_subconnector_enum_list)
> >
> > +static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
> > + { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-
> > out and DP */
> > + { DRM_MODE_SUBCONNECTOR_VGA, "VGA" }, /* DP */
> > + { DRM_MODE_SUBCONNECTOR_DVID,"DVI-D" }, /* DP */
> > + { DRM_MODE_SUBCONNECTOR_HDMIA, "HDMI" }, /* DP */
> > + { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
> > + { DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
> > + { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
> > +};
> > +
> > +DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
> > +drm_dp_subconnector_enum_list)
> > +
> > static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> > /* For Default case, driver will set the colorspace */
> > { DRM_MODE_COLORIMETRY_DEFAULT, "Default" }, @@ -1186,6 +1199,14
> @@
> > static
Re: [Intel-gfx] [PATCH 1/5] drm: report dp downstream port type as a subconnector property
> -Original Message-
> From: B, Jeevan
> Sent: Wednesday, April 1, 2020 5:42 PM
> To: Shankar, Uma
> Cc: B, Jeevan ; Ville Syrjälä
> ;
> intel-gfx@lists.freedesktop.org
> Subject: [PATCH 1/5] drm: report dp downstream port type as a subconnector
> property
>
> Currently, downstream port type is only reported in debugfs. This information
> should
> be considered important since it reflects the actual physical connector type.
> Some
> userspace (e.g. window compositors) may want to show this info to a user.
>
> The 'subconnector' property is already utilized for DVI-I and TV-out for
> reporting
> connector subtype.
>
> The initial motivation for this feature came from i2c test [1].
> It is supposed to be skipped on VGA connectors, but it cannot detect VGA over
> DP
> and fails instead.
>
> v2:
> - Ville: utilized drm_dp_is_branch()
> - Ville: implement DP 1.0 downstream type info
> - Replaced create_dp_properties with add_dp_subconnector_property
> - Added dp_set_subconnector_property helper
>
> v4:
> - Ville: add DP1.0 best assumption about subconnector
> - Ville: assume DVI is DVI-D
> - Ville: reuse Writeback enum value for Virtual subconnector
> - Renamed #defines: HDMI -> HDMIA, DP -> DisplayPort
>
> [1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097
>
> Reviewed-by: Emil Velikov
> Signed-off-by: Oleg Vasilev
> Cc: Ville Syrjälä
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Jeevan B
You can update the version number for this series : use subject-prefix=v5 as
git-format.
Also move your signed off close to Oleg's. Best is to put Cc: at the top, then
all
Signed-off and Reviewed-by
Also in patch mention change in v5, like if it's just rebased
V5: rebase
> Link: https://patchwork.freedesktop.org/patch/msgid/20190829114854.1539-3-
> oleg.vasi...@intel.com
> ---
> drivers/gpu/drm/drm_connector.c | 49 --
> drivers/gpu/drm/drm_dp_helper.c | 77
> +
> include/drm/drm_connector.h | 3 ++
> include/drm/drm_dp_helper.h | 8 +
> include/drm/drm_mode_config.h | 6
> include/uapi/drm/drm_mode.h | 21 ++-
> 6 files changed, 154 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b1099e1..b6972d1 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -844,7 +844,7 @@ static const struct drm_prop_enum_list
> drm_dvi_i_select_enum_list[] = {
> DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
>
> static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] = {
> - { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and
> TV-out */
> + { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-
> out and DP */
> { DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
> { DRM_MODE_SUBCONNECTOR_DVIA, "DVI-A" }, /* DVI-I */
> };
> @@ -861,7 +861,7 @@ static const struct drm_prop_enum_list
> drm_tv_select_enum_list[] = { DRM_ENUM_NAME_FN(drm_get_tv_select_name,
> drm_tv_select_enum_list)
>
> static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] = {
> - { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and
> TV-out */
> + { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-
> out and DP */
> { DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
> { DRM_MODE_SUBCONNECTOR_SVIDEO,"SVIDEO"}, /* TV-out */
> { DRM_MODE_SUBCONNECTOR_Component, "Component" }, /* TV-out */
> @@ -870,6 +870,19 @@ static const struct drm_prop_enum_list
> drm_tv_subconnector_enum_list[] = {
> DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>
> +static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
> + { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-
> out and DP */
> + { DRM_MODE_SUBCONNECTOR_VGA, "VGA" }, /* DP */
> + { DRM_MODE_SUBCONNECTOR_DVID,"DVI-D" }, /* DP */
> + { DRM_MODE_SUBCONNECTOR_HDMIA, "HDMI" }, /* DP */
> + { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
> + { DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
> + { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
> +};
> +
> +DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
> + drm_dp_subconnector_enum_list)
> +
> static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> /* For Default case, driver will set the colorspace */
> { DRM_MODE_COLORIMETRY_DEFAULT, "Default" }, @@ -1186,6 +1199,14
> @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
> * can also expose this property to external outputs, in which case they
> * must support "None", which should be the default (since external screens
> * have a built-in scaler).
> + *
> + *
[Intel-gfx] [PATCH 1/5] drm: report dp downstream port type as a subconnector property
Currently, downstream port type is only reported in debugfs. This
information should be considered important since it reflects the actual
physical connector type. Some userspace (e.g. window compositors)
may want to show this info to a user.
The 'subconnector' property is already utilized for DVI-I and TV-out for
reporting connector subtype.
The initial motivation for this feature came from i2c test [1].
It is supposed to be skipped on VGA connectors, but it cannot
detect VGA over DP and fails instead.
v2:
- Ville: utilized drm_dp_is_branch()
- Ville: implement DP 1.0 downstream type info
- Replaced create_dp_properties with add_dp_subconnector_property
- Added dp_set_subconnector_property helper
v4:
- Ville: add DP1.0 best assumption about subconnector
- Ville: assume DVI is DVI-D
- Ville: reuse Writeback enum value for Virtual subconnector
- Renamed #defines: HDMI -> HDMIA, DP -> DisplayPort
[1]: https://bugs.freedesktop.org/show_bug.cgi?id=104097
Reviewed-by: Emil Velikov
Signed-off-by: Oleg Vasilev
Cc: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Jeevan B
Link:
https://patchwork.freedesktop.org/patch/msgid/20190829114854.1539-3-oleg.vasi...@intel.com
---
drivers/gpu/drm/drm_connector.c | 49 --
drivers/gpu/drm/drm_dp_helper.c | 77 +
include/drm/drm_connector.h | 3 ++
include/drm/drm_dp_helper.h | 8 +
include/drm/drm_mode_config.h | 6
include/uapi/drm/drm_mode.h | 21 ++-
6 files changed, 154 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b1099e1..b6972d1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -844,7 +844,7 @@ static const struct drm_prop_enum_list
drm_dvi_i_select_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_dvi_i_select_name, drm_dvi_i_select_enum_list)
static const struct drm_prop_enum_list drm_dvi_i_subconnector_enum_list[] = {
- { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
+ { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-out and
DP */
{ DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
{ DRM_MODE_SUBCONNECTOR_DVIA, "DVI-A" }, /* DVI-I */
};
@@ -861,7 +861,7 @@ static const struct drm_prop_enum_list
drm_tv_select_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_tv_select_name, drm_tv_select_enum_list)
static const struct drm_prop_enum_list drm_tv_subconnector_enum_list[] = {
- { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I and TV-out */
+ { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-out and
DP */
{ DRM_MODE_SUBCONNECTOR_Composite, "Composite" }, /* TV-out */
{ DRM_MODE_SUBCONNECTOR_SVIDEO,"SVIDEO"}, /* TV-out */
{ DRM_MODE_SUBCONNECTOR_Component, "Component" }, /* TV-out */
@@ -870,6 +870,19 @@ static const struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
+static const struct drm_prop_enum_list drm_dp_subconnector_enum_list[] = {
+ { DRM_MODE_SUBCONNECTOR_Unknown, "Unknown" }, /* DVI-I, TV-out
and DP */
+ { DRM_MODE_SUBCONNECTOR_VGA, "VGA" }, /* DP */
+ { DRM_MODE_SUBCONNECTOR_DVID,"DVI-D" }, /* DP */
+ { DRM_MODE_SUBCONNECTOR_HDMIA, "HDMI" }, /* DP */
+ { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
+ { DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
+ { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
+};
+
+DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
+drm_dp_subconnector_enum_list)
+
static const struct drm_prop_enum_list hdmi_colorspaces[] = {
/* For Default case, driver will set the colorspace */
{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
@@ -1186,6 +1199,14 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* can also expose this property to external outputs, in which case they
* must support "None", which should be the default (since external screens
* have a built-in scaler).
+ *
+ * subconnector:
+ * This property is used by DVI-I, TVout and DisplayPort to indicate
different
+ * connector subtypes. Enum values more or less match with those from main
+ * connector types.
+ * For DVI-I and TVout there is also a matching property "select
subconnector"
+ * allowing to switch between signal types.
+ * DP subconnector corresponds to a downstream port.
*/
int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1275,6 +1296,30 @@ int drm_mode_create_dvi_i_properties(struct drm_device
*dev)
EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
/**
+ * drm_mode_add_dp_subconnector_property - create subconnector property for DP
+ *
[Intel-gfx] [PATCH 2/5] drm/i915: utilize subconnector property for DP
Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: updates to match previous commit changes Reviewed-by: Emil Velikov Tested-by: Oleg Vasilev Signed-off-by: Oleg Vasilev Cc: Ville Syrjälä Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Jeevan B Link: https://patchwork.freedesktop.org/patch/msgid/20190829114854.1539-4-oleg.vasi...@intel.com --- drivers/gpu/drm/i915/display/intel_dp.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 2e715e6..c2c9ed3 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -6140,6 +6140,11 @@ intel_dp_detect(struct drm_connector *connector, */ intel_display_power_flush_work(dev_priv); + if (!intel_dp_is_edp(intel_dp)) + drm_dp_set_subconnector_property(connector, +status, +intel_dp->dpcd, +intel_dp->downstream_ports); return status; } @@ -7192,6 +7197,9 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connect struct drm_i915_private *dev_priv = to_i915(connector->dev); enum port port = dp_to_dig_port(intel_dp)->base.port; + if (!intel_dp_is_edp(intel_dp)) + drm_mode_add_dp_subconnector_property(connector); + if (!IS_G4X(dev_priv) && port != PORT_A) intel_attach_force_audio_property(connector); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915/display: Add intel_aux_ch_to_power_domain()
On Tue, Mar 31, 2020 at 05:41:17PM -0700, José Roberto de Souza wrote:
> This is a similar function to intel_aux_power_domain() but it do not
> care about TBT ports, this will be needed by GEN11 TC sequences.
>
> Cc: Imre Deak
> Cc: Cooper Chiou
> Cc: Kai-Heng Feng
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 14 --
> drivers/gpu/drm/i915/display/intel_display.h | 2 ++
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e09a11b1e509..7e06d2306dcd 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7278,7 +7278,17 @@ intel_aux_power_domain(struct intel_digital_port
> *dig_port)
> }
> }
>
> - switch (dig_port->aux_ch) {
> + return intel_aux_ch_to_power_domain(dig_port->aux_ch);
> +}
> +
> +/*
> + * Converts aux_ch to power_domain without caring about TBT ports for that
> use
> + * intel_aux_power_domain()
> + */
> +enum intel_display_power_domain
> +intel_aux_ch_to_power_domain(enum aux_ch aux_ch)
Maybe intel_legacy_aux_to_power_domain()?
> +{
> + switch (aux_ch) {
> case AUX_CH_A:
> return POWER_DOMAIN_AUX_A;
> case AUX_CH_B:
> @@ -7294,7 +7304,7 @@ intel_aux_power_domain(struct intel_digital_port
> *dig_port)
> case AUX_CH_G:
> return POWER_DOMAIN_AUX_G;
> default:
> - MISSING_CASE(dig_port->aux_ch);
> + MISSING_CASE(aux_ch);
> return POWER_DOMAIN_AUX_A;
> }
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index adb1225a3480..ad50119c0453 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -579,6 +579,8 @@ void hsw_disable_ips(const struct intel_crtc_state
> *crtc_state);
> enum intel_display_power_domain intel_port_to_power_domain(enum port port);
> enum intel_display_power_domain
> intel_aux_power_domain(struct intel_digital_port *dig_port);
> +enum intel_display_power_domain
> +intel_aux_ch_to_power_domain(enum aux_ch aux_ch);
> void intel_mode_from_pipe_config(struct drm_display_mode *mode,
>struct intel_crtc_state *pipe_config);
> void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
> --
> 2.26.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH -next] drm/i915/gt: fix spelling mistake "undeflow" -> "underflow"
There is a spelling mistake in comment, fix it. Signed-off-by: Chen Zhou --- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c index b6cf284..3be6797 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c @@ -181,7 +181,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs *engine) * Ergo, if we put ourselves on the timelines.active_list * (se intel_timeline_enter()) before we increment the * engine->wakeref.count, we may see the request completion and retire -* it causing an undeflow of the engine->wakeref. +* it causing an underflow of the engine->wakeref. */ flags = __timeline_mark_lock(ce); GEM_BUG_ON(atomic_read(>timeline->active_count) < 0); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/display: Move out code to return the digital_port of the aux ch
On 2020-04-01 08:41, José Roberto de Souza wrote:
> Moving the code to return the digital port of the aux channel also
> removing the intel_phy_is_tc() to make it generic.
> digital_port will be needed in icl_tc_phy_aux_power_well_enable()
> so adding it as a parameter to icl_tc_port_assert_ref_held().
>
> While at at removing the duplicated call to icl_tc_phy_aux_ch() in
> icl_tc_port_assert_ref_held().
>
> Signed-off-by: José Roberto de Souza
> ---
> .../drm/i915/display/intel_display_power.c| 38 ++-
> 1 file changed, 21 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 433e5a81dd4d..02a07aa710e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -500,26 +500,14 @@ static int power_well_async_ref_count(struct
> drm_i915_private *dev_priv,
> return refs;
> }
>
> -static void icl_tc_port_assert_ref_held(struct drm_i915_private *dev_priv,
> - struct i915_power_well *power_well)
> +static struct intel_digital_port *
> +aux_ch_to_digital_port(struct drm_i915_private *dev_priv,
> +enum aux_ch aux_ch)
This fails the build because icl_tc_port_assert_ref_held was originally
guarded by CONFIG_DRM_I915_DEBUG_RUNTIME_PM, but now
aux_ch_to_digital_port maybe used outside the scope.
> {
> - enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
> struct intel_digital_port *dig_port = NULL;
> struct intel_encoder *encoder;
>
> - /* Bypass the check if all references are released asynchronously */
> - if (power_well_async_ref_count(dev_priv, power_well) ==
> - power_well->count)
> - return;
> -
> - aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
> -
> for_each_intel_encoder(_priv->drm, encoder) {
> - enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> -
> - if (!intel_phy_is_tc(dev_priv, phy))
> - continue;
> -
> /* We'll check the MST primary port */
> if (encoder->type == INTEL_OUTPUT_DP_MST)
> continue;
> @@ -536,6 +524,18 @@ static void icl_tc_port_assert_ref_held(struct
> drm_i915_private *dev_priv,
> break;
> }
>
> + return dig_port;
> +}
> +
> +static void icl_tc_port_assert_ref_held(struct drm_i915_private *dev_priv,
> + struct i915_power_well *power_well,
> + struct intel_digital_port *dig_port)
> +{
> + /* Bypass the check if all references are released asynchronously */
> + if (power_well_async_ref_count(dev_priv, power_well) ==
> + power_well->count)
> + return;
> +
> if (drm_WARN_ON(_priv->drm, !dig_port))
> return;
>
> @@ -558,9 +558,10 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private
> *dev_priv,
>struct i915_power_well *power_well)
> {
> enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
> + struct intel_digital_port *dig_port = aux_ch_to_digital_port(dev_priv,
> aux_ch);
E.g. here.
> u32 val;
>
> - icl_tc_port_assert_ref_held(dev_priv, power_well);
> + icl_tc_port_assert_ref_held(dev_priv, power_well, dig_port);
>
> val = intel_de_read(dev_priv, DP_AUX_CH_CTL(aux_ch));
> val &= ~DP_AUX_CH_CTL_TBT_IO;
> @@ -588,7 +589,10 @@ static void
> icl_tc_phy_aux_power_well_disable(struct drm_i915_private *dev_priv,
> struct i915_power_well *power_well)
> {
> - icl_tc_port_assert_ref_held(dev_priv, power_well);
> + enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
> + struct intel_digital_port *dig_port = aux_ch_to_digital_port(dev_priv,
> aux_ch);
> +
> + icl_tc_port_assert_ref_held(dev_priv, power_well, dig_port);
>
> hsw_power_well_disable(dev_priv, power_well);
> }
>
You-Sheng Yang
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Extend hotplug detect retry on TypeC connectors to 5 seconds
On Wed, Apr 01, 2020 at 04:50:23PM +0530, Anshuman Gupta wrote:
> On 2020-03-30 at 15:24:25 +0530, Imre Deak wrote:
> > On TypeC ports if a sink deasserts/reasserts its HPD signal, generating
> > a hotplug interrupt without the sink getting unplugged/replugged from
> > the connector, there can be an up to 3 seconds delay until the AUX
> > channel gets functional. To avoid detection failures this delay causes
> > retry the detection for 5 seconds.
> >
> > I noticed this on ICL/TGL RVPs and a DELL XPS 13 7390 ICL laptop.
> >
> > References: https://gitlab.freedesktop.org/drm/intel/issues/1067
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 4f508bf70f3b..2d947ff83488 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4371,7 +4371,10 @@ static enum intel_hotplug_state
> > intel_ddi_hotplug(struct intel_encoder *encoder,
> > struct intel_connector *connector)
> > {
> > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > + enum phy phy = intel_port_to_phy(i915, encoder->port);
> > + bool is_tc = intel_phy_is_tc(i915, phy);
> > struct drm_modeset_acquire_ctx ctx;
> > enum intel_hotplug_state state;
> > int ret;
> > @@ -4414,8 +4417,15 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
> > * valid EDID. To solve this schedule another detection cycle if this
> > * time around we didn't detect any change in the sink's connection
> > * status.
> > +*
> > +* Type-c connectors which get their HPD signal deasserted then
> > +* reasserted, without unplugging/replugging the sink from the
> > +* connector, introduce a delay until the AUX channel communication
> > +* becomes functional. Retry the detection for 5 seconds on type-c
> > +* connectors to account for this delay.
> > */
> > - if (state == INTEL_HOTPLUG_UNCHANGED && !connector->hotplug_retries &&
> > + if (state == INTEL_HOTPLUG_UNCHANGED &&
> > + connector->hotplug_retries < (is_tc ? 5 : 1) &&
>
> I had observed that intel_dp_detect may race between user spece
> invoked get connector call and intel_encoder_hotplug(), that may leave
> connector status to be UNCHANGED in actual hotplug flow as
> intel_dp_detect() already called from
> drm_helper_probe_single_connector_modes(), this may results in 5
> retries for type-C ports for normal HPD assertion. Please correct me
> if i am wrong.
Yes, it's possible the retries will be unneccessary, but I don't think
we can do much about avoiding a race between a hotplug event and a
detect call.
> Thanks,
> Anshuman Gupta.
> > !dig_port->dp.is_mst)
> > state = INTEL_HOTPLUG_RETRY;
> >
> > --
> > 2.23.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
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Peek at the next submission for error interrupts
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Peek at the next submission for error interrupts URL : https://patchwork.freedesktop.org/series/75362/ State : success == Summary == CI Bug Log - changes from CI_DRM_8231 -> Patchwork_17168 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17168/index.html Known issues Here are the changes found in Patchwork_17168 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@common-hpd-after-suspend: - fi-cml-u2: [PASS][1] -> [DMESG-WARN][2] ([IGT#4]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8231/fi-cml-u2/igt@kms_chamel...@common-hpd-after-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17168/fi-cml-u2/igt@kms_chamel...@common-hpd-after-suspend.html Possible fixes * igt@gem_wait@basic-await-all: - fi-byt-n2820: [FAIL][3] -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8231/fi-byt-n2820/igt@gem_w...@basic-await-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17168/fi-byt-n2820/igt@gem_w...@basic-await-all.html [IGT#4]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/4 Participating hosts (49 -> 43) -- Additional (2): fi-skl-6770hq fi-tgl-dsi Missing(8): fi-hsw-4200u fi-byt-j1900 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8231 -> Patchwork_17168 CI-20190529: 20190529 CI_DRM_8231: e262993871d01ae0ee71477ffc92752305cd2bb5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5550: 98927dfde17aecaecfe67bb9853ceca326ca2b23 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17168: cfc4b332219941e947762ea13f2e25a88d86c734 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == cfc4b3322199 drm/i915/execlists: Record the active CCID from before reset c77a5b25db60 drm/i915/execlists: Peek at the next submission for error interrupts == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17168/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Extend hotplug detect retry on TypeC connectors to 5 seconds
On 2020-03-30 at 15:24:25 +0530, Imre Deak wrote:
> On TypeC ports if a sink deasserts/reasserts its HPD signal, generating
> a hotplug interrupt without the sink getting unplugged/replugged from
> the connector, there can be an up to 3 seconds delay until the AUX
> channel gets functional. To avoid detection failures this delay causes
> retry the detection for 5 seconds.
>
> I noticed this on ICL/TGL RVPs and a DELL XPS 13 7390 ICL laptop.
>
> References: https://gitlab.freedesktop.org/drm/intel/issues/1067
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 4f508bf70f3b..2d947ff83488 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4371,7 +4371,10 @@ static enum intel_hotplug_state
> intel_ddi_hotplug(struct intel_encoder *encoder,
> struct intel_connector *connector)
> {
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> + bool is_tc = intel_phy_is_tc(i915, phy);
> struct drm_modeset_acquire_ctx ctx;
> enum intel_hotplug_state state;
> int ret;
> @@ -4414,8 +4417,15 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
>* valid EDID. To solve this schedule another detection cycle if this
>* time around we didn't detect any change in the sink's connection
>* status.
> + *
> + * Type-c connectors which get their HPD signal deasserted then
> + * reasserted, without unplugging/replugging the sink from the
> + * connector, introduce a delay until the AUX channel communication
> + * becomes functional. Retry the detection for 5 seconds on type-c
> + * connectors to account for this delay.
>*/
> - if (state == INTEL_HOTPLUG_UNCHANGED && !connector->hotplug_retries &&
> + if (state == INTEL_HOTPLUG_UNCHANGED &&
> + connector->hotplug_retries < (is_tc ? 5 : 1) &&
I had observed that intel_dp_detect may race between user spece invoked
get connector call and intel_encoder_hotplug(), that may leave connector status
to be UNCHANGED in actual hotplug flow as intel_dp_detect() already called from
drm_helper_probe_single_connector_modes(), this may results in 5 retries for
type-C ports for normal HPD assertion.
Please correct me if i am wrong.
Thanks,
Anshuman Gupta.
> !dig_port->dp.is_mst)
> state = INTEL_HOTPLUG_RETRY;
>
> --
> 2.23.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
[Intel-gfx] [CI] drm/i915/gt: Align engine dump active/pending
Insert a space so that the same fields between active/pending execlists state are aligned. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index b01af08eaaf7..843cb6f2f696 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -1405,7 +1405,7 @@ static void intel_engine_print_registers(struct intel_engine_cs *engine, int len; len = scnprintf(hdr, sizeof(hdr), - "\t\tActive[%d]: ccid:%08x, ", + "\t\tActive[%d]: ccid:%08x, ", (int)(port - execlists->active), upper_32_bits(rq->context->lrc_desc)); len += print_ring(hdr + len, sizeof(hdr) - len, rq); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Peek at the next submission for error interrupts
If we receive the error interrupt before the CS interrupt, we may find
ourselves without an active request to reset, skipping the GPU reset.
All because the attempt to reset was too early.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3479cda37fdc..f028114714cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2804,6 +2804,45 @@ static struct execlists_capture *capture_regs(struct
intel_engine_cs *engine)
return NULL;
}
+static struct i915_request *
+active_context(struct intel_engine_cs *engine, u32 ccid)
+{
+ const struct intel_engine_execlists * const el = >execlists;
+ struct i915_request * const *port, *rq;
+
+ /*
+* Use the most recent result from process_csb(), but just in case
+* we trigger an error (via interrupt) before the first CS event has
+* been written, peek at the next submission.
+*/
+
+ for (port = el->active; (rq = *port); port++) {
+ if (upper_32_bits(rq->context->lrc_desc) == ccid) {
+ ENGINE_TRACE(engine,
+"ccid found at active:%zd\n",
+port - el->active);
+ return rq;
+ }
+ }
+
+ for (port = el->pending; (rq = *port); port++) {
+ if (upper_32_bits(rq->context->lrc_desc) == ccid) {
+ ENGINE_TRACE(engine,
+"ccid found at pending:%zd\n",
+port - el->pending);
+ return rq;
+ }
+ }
+
+ ENGINE_TRACE(engine, "ccid:%x not found\n", ccid);
+ return NULL;
+}
+
+static u32 active_ccid(struct intel_engine_cs *engine)
+{
+ return ENGINE_READ_FW(engine, RING_EXECLIST_STATUS_HI);
+}
+
static bool execlists_capture(struct intel_engine_cs *engine)
{
struct execlists_capture *cap;
@@ -2821,7 +2860,7 @@ static bool execlists_capture(struct intel_engine_cs
*engine)
return true;
spin_lock_irq(>active.lock);
- cap->rq = execlists_active(>execlists);
+ cap->rq = active_context(engine, active_ccid(engine));
if (cap->rq) {
cap->rq = active_request(cap->rq->context->timeline, cap->rq);
cap->rq = i915_request_get_rcu(cap->rq);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/execlists: Record the active CCID from before reset
If we cannot trust the reset will flush out the CS event queue such that
process_csb() reports an accurate view of HW, we will need to search the
active and pending contexts to determine which was actually running at
the time we issued the reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 80cdde712842..4804587442e7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -166,6 +166,11 @@ struct intel_engine_execlists {
*/
u32 error_interrupt;
+ /**
+* @reset_ccid: Active CCID [EXECLISTS_STATUS_HI] at the time of reset
+*/
+ u32 reset_ccid;
+
/**
* @no_priolist: priority lists disabled
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index f028114714cd..55bf3cdf3b38 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3724,6 +3724,8 @@ static void execlists_reset_prepare(struct
intel_engine_cs *engine)
*/
ring_set_paused(engine, 1);
intel_engine_stop_cs(engine);
+
+ engine->execlists.reset_ccid = active_ccid(engine);
}
static void reset_csb_pointers(struct intel_engine_cs *engine)
@@ -3798,7 +3800,7 @@ static void __execlists_reset(struct intel_engine_cs
*engine, bool stalled)
* its request, it was still running at the time of the
* reset and will have been clobbered.
*/
- rq = execlists_active(execlists);
+ rq = active_context(engine, engine->execlists.reset_ccid);
if (!rq)
goto unwind;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Utilize rcu iteration of context engines (rev2)
== Series Details == Series: drm/i915/gem: Utilize rcu iteration of context engines (rev2) URL : https://patchwork.freedesktop.org/series/75270/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8223_full -> Patchwork_17151_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17151_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17151_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_17151_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@requests: - shard-tglb: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-tglb8/igt@i915_selftest@l...@requests.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/shard-tglb1/igt@i915_selftest@l...@requests.html New tests - New tests have been introduced between CI_DRM_8223_full and Patchwork_17151_full: ### New IGT tests (1) ### * igt@gem_exec_capture@capture: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_17151_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@implicit-both-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-iclb3/igt@gem_exec_sched...@implicit-both-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-iclb7/igt@gem_exec_sched...@in-order-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/shard-iclb2/igt@gem_exec_sched...@in-order-bsd.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-kbl3/igt@gem_soft...@noreloc-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/shard-kbl7/igt@gem_soft...@noreloc-s3.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-offscreen: - shard-apl: [PASS][11] -> [FAIL][12] ([i915#54] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-apl3/igt@kms_cursor_...@pipe-a-cursor-128x42-offscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/shard-apl3/igt@kms_cursor_...@pipe-a-cursor-128x42-offscreen.html * igt@kms_cursor_crc@pipe-a-cursor-alpha-transparent: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#54]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-skl5/igt@kms_cursor_...@pipe-a-cursor-alpha-transparent.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/shard-skl2/igt@kms_cursor_...@pipe-a-cursor-alpha-transparent.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#79]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-skl7/igt@kms_f...@flip-vs-expired-vblank.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/shard-skl2/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-glk2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/shard-glk1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@plain-flip-ts-check: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#34]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-glk2/igt@kms_f...@plain-flip-ts-check.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17151/shard-glk1/igt@kms_f...@plain-flip-ts-check.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180] / [i915#93] / [i915#95]) +1 similar issue [21]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Include the execlists CCID of each port in the engine dump
== Series Details == Series: drm/i915/gt: Include the execlists CCID of each port in the engine dump URL : https://patchwork.freedesktop.org/series/75298/ State : success == Summary == CI Bug Log - changes from CI_DRM_8223_full -> Patchwork_17150_full Summary --- **SUCCESS** No regressions found. New tests - New tests have been introduced between CI_DRM_8223_full and Patchwork_17150_full: ### New IGT tests (1) ### * igt@gem_exec_capture@capture: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_17150_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +12 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-iclb2/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-iclb3/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_persistence@engines-mixed-process@rcs0: - shard-iclb: [PASS][3] -> [FAIL][4] ([i915#1528]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-iclb3/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-iclb1/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html * igt@gem_exec_schedule@implicit-both-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-iclb3/igt@gem_exec_sched...@implicit-both-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-iclb7/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@in-order-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-iclb7/igt@gem_exec_sched...@in-order-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-iclb4/igt@gem_exec_sched...@in-order-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +18 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-snb: [PASS][13] -> [TIMEOUT][14] ([i915#1526]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-snb6/igt@i915_pm_rc6_reside...@rc6-idle.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-snb5/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_suspend@fence-restore-untiled: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-kbl1/igt@i915_susp...@fence-restore-untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-kbl1/igt@i915_susp...@fence-restore-untiled.html * igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-ytiled: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#52] / [i915#54]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-glk8/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-ytiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-glk6/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-ytiled.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180] / [i915#93] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-kbl6/igt@kms_fbcon_...@fbc-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-kbl6/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#34]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-glk8/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17150/shard-glk6/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html * igt@kms_flip@plain-flip-fb-recreate: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#34]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8223/shard-skl10/igt@kms_f...@plain-flip-fb-recreate.html [24]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Make Wa_14010229206 permanent
== Series Details == Series: drm/i915/tgl: Make Wa_14010229206 permanent URL : https://patchwork.freedesktop.org/series/75139/ State : success == Summary == CI Bug Log - changes from CI_DRM_8197_full -> Patchwork_17107_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17107_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([i915#1492]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb4/igt@gem_ctx_persiste...@close-replace-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb2/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_eio@in-flight-suspend: - shard-glk: [PASS][3] -> [CRASH][4] ([i915#1582]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-glk1/igt@gem_...@in-flight-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-glk4/igt@gem_...@in-flight-suspend.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [i915#677]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb6/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([i915#677]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb3/igt@gem_exec_sched...@pi-common-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112146]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#54] / [i915#93] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-64x21-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-64x21-onscreen.html * igt@kms_cursor_crc@pipe-c-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_8197/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_draw_crc@draw-method-rgb565-blt-untiled: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#52] / [i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-glk9/igt@kms_draw_...@draw-method-rgb565-blt-untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-glk7/igt@kms_draw_...@draw-method-rgb565-blt-untiled.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#79]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-skl10/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-glk6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-glk4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-apl7/igt@kms_f...@flip-vs-suspend-interruptible.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-apl8/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#1188]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-skl9/igt@kms_...@bpc-switch-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-skl10/igt@kms_...@bpc-switch-suspend.html * igt@kms_psr@psr2_sprite_plane_move: - shard-iclb:
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Make Wa_14010229206 permanent
Hi Swathi, I have addressed the issue and re-reported the results last night. But the results were not updated. Now I am re-reporting for the second time. I will update you. I will keep you posted. Lakshmi. -Original Message- From: Dhanavanthri, Swathi Sent: Wednesday, April 1, 2020 12:17 AM To: intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana ; Peres, Martin Subject: RE: ✗ Fi.CI.IGT: failure for drm/i915/tgl: Make Wa_14010229206 permanent I am requesting to retest this patch. This patch involves changes that are for TGL only, but the errors are in ICL and GLK. These seem to be false positives. Thanks, Swathi -Original Message- From: Patchwork Sent: Friday, March 27, 2020 7:32 AM To: Dhanavanthri, Swathi Cc: intel-gfx@lists.freedesktop.org Subject: ✗ Fi.CI.IGT: failure for drm/i915/tgl: Make Wa_14010229206 permanent == Series Details == Series: drm/i915/tgl: Make Wa_14010229206 permanent URL : https://patchwork.freedesktop.org/series/75139/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8197_full -> Patchwork_17107_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17107_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17107_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_17107_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd2: - shard-iclb: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd2.html * igt@gem_eio@in-flight-suspend: - shard-glk: [PASS][2] -> [CRASH][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-glk1/igt@gem_...@in-flight-suspend.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-glk4/igt@gem_...@in-flight-suspend.html Known issues Here are the changes found in Patchwork_17107_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-iclb: [PASS][4] -> [INCOMPLETE][5] ([i915#1492]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb4/igt@gem_ctx_persiste...@close-replace-race.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb2/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#109276] / [i915#677]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb2/igt@gem_exec_sched...@implicit-read-write-bsd1.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb6/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][8] -> [SKIP][9] ([i915#677]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb3/igt@gem_exec_sched...@pi-common-bsd.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#112146]) +4 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-iclb3/igt@gem_exec_sched...@preempt-other-chain-bsd.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen: - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#54] / [i915#93] / [i915#95]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-64x21-onscreen.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-64x21-onscreen.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +5 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17107/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_draw_crc@draw-method-rgb565-blt-untiled: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#52] / [i915#54]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8197/shard-glk9/igt@kms_draw_...@draw-method-rgb565-blt-untiled.html [17]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915/selftests: Tidy up an error message for live_error_interrupt
== Series Details == Series: series starting with [1/4] drm/i915/selftests: Tidy up an error message for live_error_interrupt URL : https://patchwork.freedesktop.org/series/75296/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8222_full -> Patchwork_17149_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17149_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17149_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_17149_full: ### IGT changes ### Possible regressions * igt@drm_mm@all@evict_range: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/shard-skl10/igt@drm_mm@all@evict_range.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/shard-skl1/igt@drm_mm@all@evict_range.html Warnings * igt@kms_content_protection@lic: - shard-apl: [TIMEOUT][3] ([i915#1319]) -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/shard-apl3/igt@kms_content_protect...@lic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/shard-apl1/igt@kms_content_protect...@lic.html * igt@kms_vblank@pipe-d-ts-continuation-modeset-rpm: - shard-apl: [SKIP][5] ([fdo#109271]) -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/shard-apl3/igt@kms_vbl...@pipe-d-ts-continuation-modeset-rpm.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/shard-apl4/igt@kms_vbl...@pipe-d-ts-continuation-modeset-rpm.html New tests - New tests have been introduced between CI_DRM_8222_full and Patchwork_17149_full: ### New IGT tests (2) ### * igt@gem_exec_async@concurrent-writes: - Statuses : - Exec time: [None] s * igt@gem_exec_capture@capture: - Statuses : - Exec time: [None] s Known issues Here are the changes found in Patchwork_17149_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112080]) +10 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/shard-iclb4/igt@gem_b...@busy-vcs1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/shard-iclb3/igt@gem_b...@busy-vcs1.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#110854]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/shard-iclb2/igt@gem_exec_balan...@smoke.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/shard-iclb8/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@implicit-both-bsd1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276] / [i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/shard-iclb7/igt@gem_exec_sched...@implicit-both-bsd1.html * igt@gem_exec_schedule@pi-userfault-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([i915#677]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/shard-iclb3/igt@gem_exec_sched...@pi-userfault-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/shard-iclb1/igt@gem_exec_sched...@pi-userfault-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#112146]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/shard-kbl6/igt@gem_workarou...@suspend-resume-fd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/shard-kbl1/igt@gem_workarou...@suspend-resume-fd.html * igt@kms_cursor_crc@pipe-c-cursor-alpha-transparent: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#54]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8222/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-alpha-transparent.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17149/shard-skl10/igt@kms_cursor_...@pipe-c-cursor-alpha-transparent.html * igt@kms_draw_crc@draw-method-rgb565-render-xtiled:
Re: [Intel-gfx] [PATCH v2 08/20] drm/i915: Introduce proper dbuf state
On Tue, Feb 25, 2020 at 07:11:13PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a global state to track the dbuf slices. Gets rid of all the nasty
> coupling between state->modeset and dbuf recomputation. Also we can now
> totally nuke state->active_pipe_changes.
>
> dev_priv->wm.distrust_bios_wm still remains, but that too will get
> nuked soon.
>
> Cc: Stanislav Lisovskiy
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 67 +--
> .../drm/i915/display/intel_display_power.c| 8 +-
> .../drm/i915/display/intel_display_types.h| 13 --
> drivers/gpu/drm/i915/i915_drv.h | 11 +-
> drivers/gpu/drm/i915/intel_pm.c | 189 --
> drivers/gpu/drm/i915/intel_pm.h | 22 ++
> 6 files changed, 209 insertions(+), 101 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 6952c398cc43..659b952c8e2f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7581,6 +7581,8 @@ static void intel_crtc_disable_noatomic(struct
> intel_crtc *crtc,
> to_intel_bw_state(dev_priv->bw_obj.state);
> struct intel_cdclk_state *cdclk_state =
> to_intel_cdclk_state(dev_priv->cdclk.obj.state);
> + struct intel_dbuf_state *dbuf_state =
> + to_intel_dbuf_state(dev_priv->dbuf.obj.state);
> struct intel_crtc_state *crtc_state =
> to_intel_crtc_state(crtc->base.state);
> enum intel_display_power_domain domain;
> @@ -7654,6 +7656,8 @@ static void intel_crtc_disable_noatomic(struct
> intel_crtc *crtc,
> cdclk_state->min_voltage_level[pipe] = 0;
> cdclk_state->active_pipes &= ~BIT(pipe);
>
> + dbuf_state->active_pipes &= ~BIT(pipe);
> +
> bw_state->data_rate[pipe] = 0;
> bw_state->num_active_planes[pipe] = 0;
> }
> @@ -13991,10 +13995,10 @@ static void verify_wm_state(struct intel_crtc *crtc,
> hw_enabled_slices = intel_enabled_dbuf_slices_mask(dev_priv);
>
> if (INTEL_GEN(dev_priv) >= 11 &&
> - hw_enabled_slices != dev_priv->enabled_dbuf_slices_mask)
> + hw_enabled_slices != dev_priv->dbuf.enabled_slices)
> drm_err(_priv->drm,
> "mismatch in DBUF Slices (expected 0x%x, got 0x%x)\n",
> - dev_priv->enabled_dbuf_slices_mask,
> + dev_priv->dbuf.enabled_slices,
> hw_enabled_slices);
>
> /* planes */
> @@ -14529,9 +14533,7 @@ static int intel_modeset_checks(struct
> intel_atomic_state *state)
> state->modeset = true;
> state->active_pipes = intel_calc_active_pipes(state,
> dev_priv->active_pipes);
>
> - state->active_pipe_changes = state->active_pipes ^
> dev_priv->active_pipes;
> -
> - if (state->active_pipe_changes) {
> + if (state->active_pipes != dev_priv->active_pipes) {
> ret = _intel_atomic_lock_global_state(state);
> if (ret)
> return ret;
> @@ -15292,22 +15294,38 @@ static void
> intel_update_trans_port_sync_crtcs(struct intel_crtc *crtc,
> static void icl_dbuf_slice_pre_update(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask;
> - u8 required_slices = state->enabled_dbuf_slices_mask;
> - u8 slices_union = hw_enabled_slices | required_slices;
> + const struct intel_dbuf_state *new_dbuf_state =
> + intel_atomic_get_new_dbuf_state(state);
> + const struct intel_dbuf_state *old_dbuf_state =
> + intel_atomic_get_old_dbuf_state(state);
>
> - if (INTEL_GEN(dev_priv) >= 11 && slices_union != hw_enabled_slices)
> - gen9_dbuf_slices_update(dev_priv, slices_union);
> + if (!new_dbuf_state ||
> + new_dbuf_state->enabled_slices == old_dbuf_state->enabled_slices)
> + return;
> +
> + WARN_ON(!new_dbuf_state->base.changed);
> +
> + gen9_dbuf_slices_update(dev_priv,
> + old_dbuf_state->enabled_slices |
> + new_dbuf_state->enabled_slices);
> }
>
> static void icl_dbuf_slice_post_update(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - u8 hw_enabled_slices = dev_priv->enabled_dbuf_slices_mask;
> - u8 required_slices = state->enabled_dbuf_slices_mask;
> + const struct intel_dbuf_state *new_dbuf_state =
> + intel_atomic_get_new_dbuf_state(state);
> + const struct intel_dbuf_state *old_dbuf_state =
> + intel_atomic_get_old_dbuf_state(state);
>
> - if (INTEL_GEN(dev_priv) >= 11 && required_slices != hw_enabled_slices)
> - gen9_dbuf_slices_update(dev_priv, required_slices);
> + if
Re: [Intel-gfx] [PATCH v2 05/20] drm/i915: Make skl_compute_dbuf_slices() behave consistently for all platforms
On Mon, Mar 02, 2020 at 04:50:37PM +0200, Ville Syrjälä wrote: > On Tue, Feb 25, 2020 at 05:30:57PM +, Lisovskiy, Stanislav wrote: > > On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Currently skl_compute_dbuf_slices() returns 0 for any inactive pipe > > > on > > > icl+, but returns BIT(S1) on pre-icl for any pipe (whether it's > > > active or > > > not). Let's make the behaviour consistent and always return 0 for any > > > inactive pipe. > > > > > > Cc: Stanislav Lisovskiy > > > Signed-off-by: Ville Syrjälä > > > --- > > > drivers/gpu/drm/i915/intel_pm.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > > b/drivers/gpu/drm/i915/intel_pm.c > > > index a2e78969c0df..640f4c4fd508 100644 > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > > @@ -4408,7 +4408,7 @@ static u8 skl_compute_dbuf_slices(const struct > > > intel_crtc_state *crtc_state, > > >* For anything else just return one slice yet. > > >* Should be extended for other platforms. > > >*/ > > > - return BIT(DBUF_S1); > > > + return active_pipes & BIT(pipe) ? BIT(DBUF_S1) : 0; > > > > I think the initial idea was this won't be even called if there > > are no active pipes at all - skl_ddb_get_pipe_allocation_limits would > > bail out immediately. If there were some active pipes - then we will > > have to use slice S1 anyway - because there were simply no other slices > > available. If some pipes were inactive - they are currently skipped by > > !crtc_state->hw.active check - so I would just keep it simple and don't > > call this function for non-active pipes at all. > > That's just going to make the caller more messy by forcing it to > check for active_pipes 0 vs. not. Ie. we'd be splitting the > responsibility of computing the dbuf slices for this pipe between > skl_compute_dbuf_slices() and its caller. Not a good idea IMO. Let's ramp it up. As I understood from your comments we still need dbuf_state. I would anyway add another table for handling this in some unified manner at least, however don't want to spend another couple of month discussing that :) Reviewed-by: Stanislav Lisovskiy > > -- > Ville Syrjälä > Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Do not clear pollin for small user read buffers
On 01/04/2020 10:43, Dixit, Ashutosh wrote:
On Tue, 31 Mar 2020 23:57:57 -0700, Lionel Landwerlin wrote:
On 01/04/2020 02:14, Ashutosh Dixit wrote:
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smaller than the available data.
This change fixes this issue and allows user space to read all OA data
even when using a buffer size smaller than the available data using
multiple non-blocking reads rather than staying blocked in poll till
the next timer interrupt.
v2: Fix ret value for blocking reads (Umesh)
v3: Mistake during patch send (Ashutosh)
v4: Remove -EAGAIN from comment (Umesh)
v5: Improve condition for clearing pollin and return (Lionel)
v6: Improve blocking read loop and other cleanups (Lionel)
Cc: Umesh Nerlige Ramappa
Cc: Lionel Landwerlin
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 61 ++--
1 file changed, 11 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 28e3d76fa2e6..2f78b147bb2d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2963,49 +2963,6 @@ void i915_oa_init_reg_state(const struct intel_context
*ce,
gen8_update_reg_state_unlocked(ce, stream);
}
-/**
- * i915_perf_read_locked - _perf_stream_ops->read with error normalisation
- * @stream: An i915 perf stream
- * @file: An i915 perf stream file
- * @buf: destination buffer given by userspace
- * @count: the number of bytes userspace wants to read
- * @ppos: (inout) file seek position (unused)
- *
- * Besides wrapping _perf_stream_ops->read this provides a common place to
- * ensure that if we've successfully copied any data then reporting that takes
- * precedence over any internal error status, so the data isn't lost.
- *
- * For example ret will be -ENOSPC whenever there is more buffered data than
- * can be copied to userspace, but that's only interesting if we weren't able
- * to copy some data because it implies the userspace buffer is too small to
- * receive a single record (and we never split records).
- *
- * Another case with ret == -EFAULT is more of a grey area since it would seem
- * like bad form for userspace to ask us to overrun its buffer, but the user
- * knows best:
- *
- * http://yarchive.net/comp/linux/partial_reads_writes.html
- *
- * Returns: The number of bytes copied or a negative error code on failure.
- */
-static ssize_t i915_perf_read_locked(struct i915_perf_stream *stream,
-struct file *file,
-char __user *buf,
-size_t count,
-loff_t *ppos)
-{
- /* Note we keep the offset (aka bytes read) separate from any
-* error status so that the final check for whether we return
-* the bytes read with a higher precedence than any error (see
-* comment below) doesn't need to be handled/duplicated in
-* stream->ops->read() implementations.
-*/
- size_t offset = 0;
- int ret = stream->ops->read(stream, buf, count, );
-
- return offset ?: (ret ?: -EAGAIN);
-}
-
/**
* i915_perf_read - handles read() FOP for i915 perf stream FDs
* @file: An i915 perf stream file
@@ -3031,7 +2988,8 @@ static ssize_t i915_perf_read(struct file *file,
{
struct i915_perf_stream *stream = file->private_data;
struct i915_perf *perf = stream->perf;
- ssize_t ret;
+ size_t offset = 0;
+ int ret;
/* To ensure it's handled consistently we simply treat all
reads of
a
* disabled stream as an error. In particular it might otherwise lead
@@ -3054,13 +3012,12 @@ static ssize_t i915_perf_read(struct file *file,
return ret;
mutex_lock(>lock);
- ret = i915_perf_read_locked(stream, file,
- buf, count, ppos);
+ ret = stream->ops->read(stream, buf, count, );
mutex_unlock(>lock);
- } while (ret == -EAGAIN);
+ } while (!offset && !ret);
This doesn't sound right, !offset means it will stop as soon as some data
was written.
But for the blocking read we want to fill the buffer up to -ENOSPC.
I don't think that's true. Here's 'man 2 read': "read() attempts to read
/up to/ count bytes" and "It is not an error if this number is smaller than
the number of bytes requested".
The condition (!offset && !ret) is exactly equivalent to the condition (ret
== -EAGAIN) in the original code (currently on drm-tip). The driver is free
to unblock the blocking
Re: [Intel-gfx] [PATCH] drm/i915/perf: Do not clear pollin for small user read buffers
On Tue, 31 Mar 2020 23:57:57 -0700, Lionel Landwerlin wrote:
>
> On 01/04/2020 02:14, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the exact user buffer size is not
> > known. Blocking user space in poll can lead to data loss when the
> > buffer size used is smaller than the available data.
> >
> > This change fixes this issue and allows user space to read all OA data
> > even when using a buffer size smaller than the available data using
> > multiple non-blocking reads rather than staying blocked in poll till
> > the next timer interrupt.
> >
> > v2: Fix ret value for blocking reads (Umesh)
> > v3: Mistake during patch send (Ashutosh)
> > v4: Remove -EAGAIN from comment (Umesh)
> > v5: Improve condition for clearing pollin and return (Lionel)
> > v6: Improve blocking read loop and other cleanups (Lionel)
> >
> > Cc: Umesh Nerlige Ramappa
> > Cc: Lionel Landwerlin
> > Signed-off-by: Ashutosh Dixit
> > ---
> > drivers/gpu/drm/i915/i915_perf.c | 61 ++--
> > 1 file changed, 11 insertions(+), 50 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_perf.c
> > b/drivers/gpu/drm/i915/i915_perf.c
> > index 28e3d76fa2e6..2f78b147bb2d 100644
> > --- a/drivers/gpu/drm/i915/i915_perf.c
> > +++ b/drivers/gpu/drm/i915/i915_perf.c
> > @@ -2963,49 +2963,6 @@ void i915_oa_init_reg_state(const struct
> > intel_context *ce,
> > gen8_update_reg_state_unlocked(ce, stream);
> > }
> > -/**
> > - * i915_perf_read_locked - _perf_stream_ops->read with error
> > normalisation
> > - * @stream: An i915 perf stream
> > - * @file: An i915 perf stream file
> > - * @buf: destination buffer given by userspace
> > - * @count: the number of bytes userspace wants to read
> > - * @ppos: (inout) file seek position (unused)
> > - *
> > - * Besides wrapping _perf_stream_ops->read this provides a common
> > place to
> > - * ensure that if we've successfully copied any data then reporting that
> > takes
> > - * precedence over any internal error status, so the data isn't lost.
> > - *
> > - * For example ret will be -ENOSPC whenever there is more buffered data
> > than
> > - * can be copied to userspace, but that's only interesting if we weren't
> > able
> > - * to copy some data because it implies the userspace buffer is too small
> > to
> > - * receive a single record (and we never split records).
> > - *
> > - * Another case with ret == -EFAULT is more of a grey area since it would
> > seem
> > - * like bad form for userspace to ask us to overrun its buffer, but the
> > user
> > - * knows best:
> > - *
> > - * http://yarchive.net/comp/linux/partial_reads_writes.html
> > - *
> > - * Returns: The number of bytes copied or a negative error code on failure.
> > - */
> > -static ssize_t i915_perf_read_locked(struct i915_perf_stream *stream,
> > -struct file *file,
> > -char __user *buf,
> > -size_t count,
> > -loff_t *ppos)
> > -{
> > - /* Note we keep the offset (aka bytes read) separate from any
> > -* error status so that the final check for whether we return
> > -* the bytes read with a higher precedence than any error (see
> > -* comment below) doesn't need to be handled/duplicated in
> > -* stream->ops->read() implementations.
> > -*/
> > - size_t offset = 0;
> > - int ret = stream->ops->read(stream, buf, count, );
> > -
> > - return offset ?: (ret ?: -EAGAIN);
> > -}
> > -
> > /**
> >* i915_perf_read - handles read() FOP for i915 perf stream FDs
> >* @file: An i915 perf stream file
> > @@ -3031,7 +2988,8 @@ static ssize_t i915_perf_read(struct file *file,
> > {
> > struct i915_perf_stream *stream = file->private_data;
> > struct i915_perf *perf = stream->perf;
> > - ssize_t ret;
> > + size_t offset = 0;
> > + int ret;
> > /* To ensure it's handled consistently we simply treat all
> > reads of
> > a
> > * disabled stream as an error. In particular it might otherwise lead
> > @@ -3054,13 +3012,12 @@ static ssize_t i915_perf_read(struct file *file,
> > return ret;
> > mutex_lock(>lock);
> > - ret = i915_perf_read_locked(stream, file,
> > - buf, count, ppos);
> > + ret = stream->ops->read(stream, buf, count, );
> > mutex_unlock(>lock);
> > - } while (ret == -EAGAIN);
> > + } while (!offset && !ret);
>
> This doesn't sound right, !offset means it will stop as soon as some data
> was written.
>
> But for the blocking read we want to fill the buffer up to -ENOSPC.
I don't think that's true. Here's 'man 2 read': "read() attempts to read
/up to/
Re: [Intel-gfx] [PATCH] drm/i915/perf: Do not clear pollin for small user read buffers
On 01/04/2020 02:14, Ashutosh Dixit wrote:
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is smaller than the available data.
This change fixes this issue and allows user space to read all OA data
even when using a buffer size smaller than the available data using
multiple non-blocking reads rather than staying blocked in poll till
the next timer interrupt.
v2: Fix ret value for blocking reads (Umesh)
v3: Mistake during patch send (Ashutosh)
v4: Remove -EAGAIN from comment (Umesh)
v5: Improve condition for clearing pollin and return (Lionel)
v6: Improve blocking read loop and other cleanups (Lionel)
Cc: Umesh Nerlige Ramappa
Cc: Lionel Landwerlin
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 61 ++--
1 file changed, 11 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 28e3d76fa2e6..2f78b147bb2d 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2963,49 +2963,6 @@ void i915_oa_init_reg_state(const struct intel_context
*ce,
gen8_update_reg_state_unlocked(ce, stream);
}
-/**
- * i915_perf_read_locked - _perf_stream_ops->read with error normalisation
- * @stream: An i915 perf stream
- * @file: An i915 perf stream file
- * @buf: destination buffer given by userspace
- * @count: the number of bytes userspace wants to read
- * @ppos: (inout) file seek position (unused)
- *
- * Besides wrapping _perf_stream_ops->read this provides a common place to
- * ensure that if we've successfully copied any data then reporting that takes
- * precedence over any internal error status, so the data isn't lost.
- *
- * For example ret will be -ENOSPC whenever there is more buffered data than
- * can be copied to userspace, but that's only interesting if we weren't able
- * to copy some data because it implies the userspace buffer is too small to
- * receive a single record (and we never split records).
- *
- * Another case with ret == -EFAULT is more of a grey area since it would seem
- * like bad form for userspace to ask us to overrun its buffer, but the user
- * knows best:
- *
- * http://yarchive.net/comp/linux/partial_reads_writes.html
- *
- * Returns: The number of bytes copied or a negative error code on failure.
- */
-static ssize_t i915_perf_read_locked(struct i915_perf_stream *stream,
-struct file *file,
-char __user *buf,
-size_t count,
-loff_t *ppos)
-{
- /* Note we keep the offset (aka bytes read) separate from any
-* error status so that the final check for whether we return
-* the bytes read with a higher precedence than any error (see
-* comment below) doesn't need to be handled/duplicated in
-* stream->ops->read() implementations.
-*/
- size_t offset = 0;
- int ret = stream->ops->read(stream, buf, count, );
-
- return offset ?: (ret ?: -EAGAIN);
-}
-
/**
* i915_perf_read - handles read() FOP for i915 perf stream FDs
* @file: An i915 perf stream file
@@ -3031,7 +2988,8 @@ static ssize_t i915_perf_read(struct file *file,
{
struct i915_perf_stream *stream = file->private_data;
struct i915_perf *perf = stream->perf;
- ssize_t ret;
+ size_t offset = 0;
+ int ret;
/* To ensure it's handled consistently we simply treat all reads of a
* disabled stream as an error. In particular it might otherwise lead
@@ -3054,13 +3012,12 @@ static ssize_t i915_perf_read(struct file *file,
return ret;
mutex_lock(>lock);
- ret = i915_perf_read_locked(stream, file,
- buf, count, ppos);
+ ret = stream->ops->read(stream, buf, count, );
mutex_unlock(>lock);
- } while (ret == -EAGAIN);
+ } while (!offset && !ret);
This doesn't sound right, !offset means it will stop as soon as some
data was written.
But for the blocking read we want to fill the buffer up to -ENOSPC.
while (ret >= 0) doesn't work?
-Lionel
} else {
mutex_lock(>lock);
- ret = i915_perf_read_locked(stream, file, buf, count, ppos);
+ ret = stream->ops->read(stream, buf, count, );
mutex_unlock(>lock);
}
@@ -3071,11 +3028,15 @@ static ssize_t i915_perf_read(struct file *file,
* and read() returning -EAGAIN. Clearing the oa.pollin state here
* effectively ensures we back off until the next hrtimer
Re: [Intel-gfx] [PATCH 02/23] perf/core: Only copy-to-user after completely unlocking all locks.
Hi Maarten, I love your patch! Perhaps something to improve: [auto build test WARNING on drm-tip/drm-tip] [also build test WARNING on next-20200331] [cannot apply to drm-intel/for-linux-next tip/perf/core v5.6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Maarten-Lankhorst/Revert-drm-i915-gem-Drop-relocation-slowpath/20200401-005710 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip config: x86_64-randconfig-d003-20200331 (attached as .config) compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 5227fa0c72ce55927cf4849160acb00442489937) reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree COMPILER=clang make.cross ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): >> kernel/events/core.o: warning: objtool: perf_read()+0x306: stack state >> mismatch: reg1[3]=-2-56 reg2[3]=-1+0 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
