Re: [Intel-gfx] [PATCH 1/5] drm/i915/icl: use tc_port in MG_PLL macros
enum port port)
> {
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> u32 mg_pll_div0, mg_clktop_hsclkctl;
> u32 m1, m2_int, m2_frac, div1, div2, refclk;
> u64 tmp;
>
> refclk = dev_priv->cdclk.hw.ref;
>
> - mg_pll_div0 = I915_READ(MG_PLL_DIV0(port));
> - mg_clktop_hsclkctl = I915_READ(MG_CLKTOP2_HSCLKCTL(port));
> + mg_pll_div0 = I915_READ(MG_PLL_DIV0(tc_port));
> + mg_clktop_hsclkctl = I915_READ(MG_CLKTOP2_HSCLKCTL(tc_port));
>
> - m1 = I915_READ(MG_PLL_DIV1(port)) & MG_PLL_DIV1_FBPREDIV_MASK;
> + m1 = I915_READ(MG_PLL_DIV1(tc_port)) & MG_PLL_DIV1_FBPREDIV_MASK;
> m2_int = mg_pll_div0 & MG_PLL_DIV0_FBDIV_INT_MASK;
> m2_frac = (mg_pll_div0 & MG_PLL_DIV0_FRACNEN_H) ?
> (mg_pll_div0 & MG_PLL_DIV0_FBDIV_FRAC_MASK) >>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 62d61fcad89c..a5de70e6bf59 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9415,7 +9415,8 @@ static void icelake_get_ddi_pll(struct drm_i915_private
> *dev_priv,
> if (WARN_ON(!intel_dpll_is_combophy(id)))
> return;
> } else if (intel_port_is_tc(dev_priv, port)) {
> - id = icl_port_to_mg_pll_id(port);
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> + id = icl_tc_port_to_pll_id(tc_port);
Checkpatch's complaint makes sense here. You could also opt to simply
to:
id = icl_tc_port_to_pll_id(intel_port_to_tc(dev_priv, port));
> } else {
> WARN(1, "Invalid port %x\n", port);
> return;
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 606f54dde086..211b3ffa5bed 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2639,14 +2639,14 @@ int icl_calc_dp_combo_pll_link(struct
> drm_i915_private *dev_priv,
> return link_clock;
> }
>
> -static enum port icl_mg_pll_id_to_port(enum intel_dpll_id id)
> +static enum tc_port icl_pll_id_to_tc_port(enum intel_dpll_id id)
> {
> - return id - DPLL_ID_ICL_MGPLL1 + PORT_C;
> + return id - DPLL_ID_ICL_MGPLL1;
> }
>
> -enum intel_dpll_id icl_port_to_mg_pll_id(enum port port)
> +enum intel_dpll_id icl_tc_port_to_pll_id(enum tc_port tc_port)
> {
> - return port - PORT_C + DPLL_ID_ICL_MGPLL1;
> + return tc_port + DPLL_ID_ICL_MGPLL1;
> }
The "_mg_" in the name was supposed to help callers easily realize that
these functions don't make sense without mg plls. I kinda liked them,
especially in the first case where you can pass any id, which would
result in wrong code.
So, one of my fears is that there may be other patches in-flight which
touch these registers and will silently make our code use port again.
The cherry on top of this patch would be to put those enums inside
single-element structs in a way that would make gcc complain when you
accessed one instead of the other (including inside macros). Feel free
to implement this if you like the idea.
With the checkpatch error addressed and the improved commit message:
Reviewed-by: Paulo Zanoni
>
> bool intel_dpll_is_combophy(enum intel_dpll_id id)
> @@ -2925,7 +2925,10 @@ icl_get_dpll(struct intel_crtc *crtc, struct
> intel_crtc_state *crtc_state,
> ret = icl_calc_dpll_state(crtc_state, encoder, clock,
> &pll_state);
> } else {
> - min = icl_port_to_mg_pll_id(port);
> + enum tc_port tc_port;
> +
> + tc_port = intel_port_to_tc(dev_priv, port);
> + min = icl_tc_port_to_pll_id(tc_port);
> max = min;
> ret = icl_calc_mg_pll_state(crtc_state, encoder, clock,
> &pll_state);
> @@ -2959,12 +2962,8 @@ static i915_reg_t icl_pll_id_to_enable_reg(enum
> intel_dpll_id id)
> return CNL_DPLL_ENABLE(id);
> else if (id == DPLL_ID_ICL_TBTPLL)
> return TBT_PLL_ENABLE;
> - else
> - /*
> - * TODO: Make MG_PLL macros use
> - * tc port id instead of port id
> - */
> - return MG_PLL_ENABLE(icl_mg_pll_id_to_port(id));
> +
> + return MG_PLL_ENABLE(icl_pll_id_to_tc_port(id));
> }
>
> static bool icl_pll_get_hw_state(struct drm_i915_private *dev_priv,
> @@ -2974,7 +2973,6 @@ static bool icl_pll_get_hw_state(struct
>
Re: [Intel-gfx] [PATCH 3/5] drm/i915/icl: remove dpll from clk_sel
Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu:
> We should not pass DPLL_ID_ICL_DPLL0 or DPLL_ID_ICL_DPLL1 to this
> function because the path is only taken for non-combophy ports. Let the
> warning trigger if improper value is given.
>
> While at it, rename the function to match the register name we are
> trying to program.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 4dc03e8c6c10..94d0fdc14b42 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -995,7 +995,7 @@ static uint32_t hsw_pll_to_ddi_pll_sel(const struct
> intel_shared_dpll *pll)
> }
> }
>
> -static uint32_t icl_pll_to_ddi_pll_sel(struct intel_encoder *encoder,
> +static uint32_t icl_pll_to_ddi_clk_sel(struct intel_encoder *encoder,
> const struct intel_crtc_state
> *crtc_state)
> {
> const struct intel_shared_dpll *pll = crtc_state->shared_dpll;
> @@ -1004,10 +1004,11 @@ static uint32_t icl_pll_to_ddi_pll_sel(struct
> intel_encoder *encoder,
>
> switch (id) {
> default:
> + /*
> + * DPLL_ID_ICL_DPLL0 and DPLL_ID_ICL_DPLL1 should not be use
s/use/used/
With that:
Reviewed-by: Paulo Zanoni
> + * here, so do warn if this get passed in
> + */
> MISSING_CASE(id);
> - /* fall through */
> - case DPLL_ID_ICL_DPLL0:
> - case DPLL_ID_ICL_DPLL1:
> return DDI_CLK_SEL_NONE;
> case DPLL_ID_ICL_TBTPLL:
> switch (clock) {
> @@ -2869,7 +2870,7 @@ static void intel_ddi_clk_select(struct intel_encoder
> *encoder,
> if (IS_ICELAKE(dev_priv)) {
> if (!intel_port_is_combophy(dev_priv, port))
> I915_WRITE(DDI_CLK_SEL(port),
> -icl_pll_to_ddi_pll_sel(encoder, crtc_state));
> +icl_pll_to_ddi_clk_sel(encoder, crtc_state));
> } else if (IS_CANNONLAKE(dev_priv)) {
> /* Configure DPCLKA_CFGCR0 to map the DPLL to the DDI. */
> val = I915_READ(DPCLKA_CFGCR0);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/icl: keep track of unused pll while looping
Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu:
> Instead of looping again on the range of plls, just keep track of one
> unused one and use it later.
>
Reviewed-by: Paulo Zanoni
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 211b3ffa5bed..8f70838ac7d8 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -247,7 +247,7 @@ intel_find_shared_dpll(struct intel_crtc *crtc,
> enum intel_dpll_id range_max)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - struct intel_shared_dpll *pll;
> + struct intel_shared_dpll *pll, *unused_pll = NULL;
> struct intel_shared_dpll_state *shared_dpll;
> enum intel_dpll_id i;
>
> @@ -257,8 +257,10 @@ intel_find_shared_dpll(struct intel_crtc *crtc,
> pll = &dev_priv->shared_dplls[i];
>
> /* Only want to check enabled timings first */
> - if (shared_dpll[i].crtc_mask == 0)
> + if (shared_dpll[i].crtc_mask == 0) {
> + unused_pll = pll;
> continue;
> + }
>
> if (memcmp(&crtc_state->dpll_hw_state,
> &shared_dpll[i].hw_state,
> @@ -273,14 +275,11 @@ intel_find_shared_dpll(struct intel_crtc *crtc,
> }
>
> /* Ok no matching timings, maybe there's a free one? */
> - for (i = range_min; i <= range_max; i++) {
> - pll = &dev_priv->shared_dplls[i];
> - if (shared_dpll[i].crtc_mask == 0) {
> - DRM_DEBUG_KMS("[CRTC:%d:%s] allocated %s\n",
> - crtc->base.base.id, crtc->base.name,
> - pll->info->name);
> - return pll;
> - }
> + if (unused_pll) {
> + DRM_DEBUG_KMS("[CRTC:%d:%s] allocated %s\n",
> + crtc->base.base.id, crtc->base.name,
> + unused_pll->info->name);
> + return unused_pll;
> }
>
> return NULL;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/icl: use tc_port in MG_PLL macros
Em qui, 2019-01-24 às 10:52 -0800, Lucas De Marchi escreveu:
> On Wed, Jan 23, 2019 at 05:15:26PM -0800, Paulo Zanoni wrote:
> > Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu:
> > > Fix the TODO leftover in the code by changing the argument in MG_PLL
> > > macros. The MG_PLL ids used to access the register values can be
> > > converted from tc_port rather than port.
> > >
> >
> > An explanation on why the new model is better would be amazing. It may
> > be obvious to you, but it's not to other people.
>
> What about:
>
> All these registers can use the TC port to calculate the right offsets
> because they are only available for TC ports. The range (PORT_C onwards)
> may not be stable and change from platform to platform. So by using the
> TC id directly we avoid having to check for the platform in the "leaf
> functions" and thus passing dev_priv around.
Works for me. Thanks.
>
>
> >
> > > The helper functions were also renamed to use "tc" as prefix to make
> > > them more generic.
> > >
> > > Signed-off-by: Lucas De Marchi
> > > ---
> > > drivers/gpu/drm/i915/i915_reg.h | 52 +-
> > > drivers/gpu/drm/i915/intel_ddi.c | 7 ++-
> > > drivers/gpu/drm/i915/intel_display.c | 3 +-
> > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 79 +--
> > > drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +-
> > > 5 files changed, 72 insertions(+), 71 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 9a1340cfda6c..de209e0fdc01 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -9545,7 +9545,7 @@ enum skl_power_gate {
> > > #define _MG_PLL3_ENABLE 0x46038
> > > #define _MG_PLL4_ENABLE 0x4603C
> > > /* Bits are the same as DPLL0_ENABLE */
> > > -#define MG_PLL_ENABLE(port) _MMIO_PORT((port) - PORT_C,
> > > _MG_PLL1_ENABLE, \
> > > +#define MG_PLL_ENABLE(tc_port) _MMIO_PORT((tc_port), _MG_PLL1_ENABLE, \
> > > _MG_PLL2_ENABLE)
> > >
> > > #define _MG_REFCLKIN_CTL_PORT1 0x16892C
> > > @@ -9554,9 +9554,9 @@ enum skl_power_gate {
> > > #define _MG_REFCLKIN_CTL_PORT4 0x16B92C
> > > #define MG_REFCLKIN_CTL_OD_2_MUX(x)((x) << 8)
> > > #define MG_REFCLKIN_CTL_OD_2_MUX_MASK (0x7 << 8)
> > > -#define MG_REFCLKIN_CTL(port) _MMIO_PORT((port) - PORT_C, \
> > > - _MG_REFCLKIN_CTL_PORT1, \
> > > - _MG_REFCLKIN_CTL_PORT2)
> > > +#define MG_REFCLKIN_CTL(tc_port) _MMIO_PORT((tc_port), \
> > > + _MG_REFCLKIN_CTL_PORT1, \
> > > + _MG_REFCLKIN_CTL_PORT2)
> > >
> > > #define _MG_CLKTOP2_CORECLKCTL1_PORT10x1688D8
> > > #define _MG_CLKTOP2_CORECLKCTL1_PORT20x1698D8
> > > @@ -9566,9 +9566,9 @@ enum skl_power_gate {
> > > #define MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO_MASK (0xff << 16)
> > > #define MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO(x) ((x) << 8)
> > > #define MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK (0xff << 8)
> > > -#define MG_CLKTOP2_CORECLKCTL1(port) _MMIO_PORT((port) - PORT_C, \
> > > - _MG_CLKTOP2_CORECLKCTL1_PORT1, \
> > > - _MG_CLKTOP2_CORECLKCTL1_PORT2)
> > > +#define MG_CLKTOP2_CORECLKCTL1(tc_port) _MMIO_PORT((tc_port), \
> > > +
> > > _MG_CLKTOP2_CORECLKCTL1_PORT1, \
> > > +
> > > _MG_CLKTOP2_CORECLKCTL1_PORT2)
> > >
> > > #define _MG_CLKTOP2_HSCLKCTL_PORT1 0x1688D4
> > > #define _MG_CLKTOP2_HSCLKCTL_PORT2 0x1698D4
> > > @@ -9586,9 +9586,9 @@ enum skl_power_gate {
> > > #define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO(x) ((x) << 8)
> > > #define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_SHIFT 8
> > > #define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK (0xf << 8)
> > > -#define MG_CLKTOP2_HSCLKCTL(port) _MMIO_PORT((port) - PORT_C, \
> > > -
Re: [Intel-gfx] [PATCH] drm/i915: Pick the first unused PLL once again
Em qua, 2019-01-30 às 20:13 +0200, Ville Syrjala escreveu:
> From: Ville Syrjälä
>
> commit 5b0bd14dcc6b ("drm/i915/icl: keep track of unused pll while
> looping") inadvertently (I presume) changed the code to pick the
> last unused dpll rather than the first unused one like we did before.
>
> While there should most likely be no harm in changing the order
> let's change back just to avoid a change in the behaviour. At
> least it might reduce the confusion when staring at logs (took
> me a while to figure out why DPLL1 being picked over DPLL0
> when the latter was most definitely available).
Reviewed-by: Paulo Zanoni
>
> Cc: Lucas De Marchi
> Cc: Paulo Zanoni
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 8f70838ac7d8..0a42d11c4c33 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -258,7 +258,8 @@ intel_find_shared_dpll(struct intel_crtc *crtc,
>
> /* Only want to check enabled timings first */
> if (shared_dpll[i].crtc_mask == 0) {
> - unused_pll = pll;
> + if (!unused_pll)
> + unused_pll = pll;
> continue;
> }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: use logical operators with boolean type
Em qui, 2019-05-02 às 11:29 +0300, Jani Nikula escreveu: > Using arithmetic operators with booleans is confusing. Switch to logical > operators. > > Cc: Paulo Zanoni > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_dp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 4e7b8d..ef4992f 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -5094,7 +5094,7 @@ static void icl_update_tc_port_type(struct > drm_i915_private *dev_priv, > enum port port = intel_dig_port->base.port; > enum tc_port_type old_type = intel_dig_port->tc_type; > > - WARN_ON(is_legacy + is_typec + is_tbt != 1); > + WARN_ON(is_legacy || is_typec || !is_tbt); This changes the meaning. You're interpreting this as: WARN_ON(is_legacy + is_typec + (is_tbt != 1)) while the original intent of the code is to be: WARN_ON((is_legacy + is_typec + is_tbt) != 1) and a quick check on operator precedence tables leads me to think the original code is indeed correct. We're asserting exactly one of these bools enabled, so the logic operation would be something like: WARN_ON((is_legacy && (is_typec || is_tbt)) || (is_typec && (is_legacy || is_tbt)) || (is_tbt && (is_legacy || is_typec)) || (!is_legacy && !is_typec && !is_tbt)) I would still prefer the arithmetic operation. > > if (is_legacy) > intel_dig_port->tc_type = TC_PORT_LEGACY; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make use of 'engine->uncore'
Em sex, 2019-04-05 às 17:34 +0100, Chris Wilson escreveu:
> The engine has a direct link to the intel_uncore mmio handler, so make
> use of it rather than going indirectly via &engine->i915->uncore.
Does it make sense to patch the uncore assignment in gen11_lock_sfc()
too in this file?
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Chris Wilson
> Cc: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reset.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reset.c
> b/drivers/gpu/drm/i915/i915_reset.c
> index ddc403ee8855..7e7342b82b78 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -469,10 +469,11 @@ static int gen11_reset_engines(struct drm_i915_private
> *i915,
>
> static int gen8_engine_reset_prepare(struct intel_engine_cs *engine)
> {
> - struct intel_uncore *uncore = &engine->i915->uncore;
> + struct intel_uncore *uncore = engine->uncore;
> int ret;
>
> - intel_uncore_write_fw(uncore, RING_RESET_CTL(engine->mmio_base),
> + intel_uncore_write_fw(uncore,
> + RING_RESET_CTL(engine->mmio_base),
> _MASKED_BIT_ENABLE(RESET_CTL_REQUEST_RESET));
>
> ret = __intel_wait_for_register_fw(uncore,
> @@ -647,7 +648,7 @@ static void reset_prepare_engine(struct intel_engine_cs
> *engine)
>* written to the powercontext is undefined and so we may lose
>* GPU state upon resume, i.e. fail to restart after a reset.
>*/
> - intel_uncore_forcewake_get(&engine->i915->uncore, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(engine->uncore, FORCEWAKE_ALL);
> engine->reset.prepare(engine);
> }
>
> @@ -719,7 +720,7 @@ static int gt_reset(struct drm_i915_private *i915,
> static void reset_finish_engine(struct intel_engine_cs *engine)
> {
> engine->reset.finish(engine);
> - intel_uncore_forcewake_put(&engine->i915->uncore, FORCEWAKE_ALL);
> + intel_uncore_forcewake_put(engine->uncore, FORCEWAKE_ALL);
> }
>
> struct i915_gpu_restart {
___
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: Convert i915_reset.c over to using uncore mmio
Em sex, 2019-04-05 às 19:57 +0100, Chris Wilson escreveu:
> Currently i915_reset.c mixes calls to intel_uncore, pci and our old
> style I915_READ mmio interfaces. Cast aside the old implicit macros,
> and harmonise on using uncore throughout.
>
> add/remove: 1/1 grow/shrink: 0/4 up/down: 65/-207 (-142)
> Function old new delta
> rmw_register - 65 +65
> gen8_reset_engines 945 942 -3
> g4x_do_reset 407 376 -31
> intel_gpu_reset 545 509 -36
> clear_register63 - -63
> i915_clear_error_registers 461 387 -74
>
> A little bit of pointer dancing elimination works wonders.
>
> Signed-off-by: Chris Wilson
> Cc: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reset.c | 125 +-
> 1 file changed, 73 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reset.c
> b/drivers/gpu/drm/i915/i915_reset.c
> index d44dc8422e8c..f50534a833ca 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -18,6 +18,28 @@
> /* XXX How to handle concurrent GGTT updates using tiling registers? */
> #define RESET_UNDER_STOP_MACHINE 0
>
> +static void rmw_register(struct intel_uncore *uncore,
> + i915_reg_t reg, u32 clr, u32 set)
> +{
> + u32 val;
> +
> + val = intel_uncore_read(uncore, reg);
> + val &= ~clr;
> + val |= set;
> + intel_uncore_write(uncore, reg, val);
> +}
> +
> +static void rmw_register_fw(struct intel_uncore *uncore,
> + i915_reg_t reg, u32 clr, u32 set)
> +{
> + u32 val;
> +
> + val = intel_uncore_read_fw(uncore, reg);
> + val &= ~clr;
> + val |= set;
> + intel_uncore_write_fw(uncore, reg, val);
> +}
I like the idea here, maybe we could expose these concepts to the whole
driver.
But one thing I did notice is that in all of the calls there's an
argument that's zero. It's easy to get confused on the set/clear
parameter order and make a mistake. Also, when reading the code we have
to keep remembering which one comes first. Perhaps some small wrappers
for the cases where we only set or clear something (currently, 100% of
the cases) would make the code even more readable:
static inline void rmw_register_set(uncore, reg, bits_to_set)
{
rmw_register(uncore, reg, 0, bits);
}
static inline void rmw_register_clear(uncore, reg, bits_to_clear)
{
rmw_register(uncore, reg, bits, 0);
}
IMHO that would make the code much more comfortable to read. But maybe
that's because my brain is just too small.
> +
> static void engine_skip_context(struct i915_request *rq)
> {
> struct intel_engine_cs *engine = rq->engine;
> @@ -119,7 +141,7 @@ void i915_reset_request(struct i915_request *rq, bool
> guilty)
>
> static void gen3_stop_engine(struct intel_engine_cs *engine)
> {
> - struct drm_i915_private *dev_priv = engine->i915;
> + struct intel_uncore *uncore = engine->uncore;
> const u32 base = engine->mmio_base;
>
> GEM_TRACE("%s\n", engine->name);
> @@ -127,20 +149,23 @@ static void gen3_stop_engine(struct intel_engine_cs
> *engine)
> if (intel_engine_stop_cs(engine))
> GEM_TRACE("%s: timed out on STOP_RING\n", engine->name);
>
> - I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
> - POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
> + intel_uncore_write_fw(uncore,
> + RING_HEAD(base),
> + intel_uncore_read_fw(uncore, RING_TAIL(base)));
> + intel_uncore_posting_read_fw(uncore, RING_HEAD(base)); /* paranoia */
>
> - I915_WRITE_FW(RING_HEAD(base), 0);
> - I915_WRITE_FW(RING_TAIL(base), 0);
> - POSTING_READ_FW(RING_TAIL(base));
> + intel_uncore_write_fw(uncore, RING_HEAD(base), 0);
> + intel_uncore_write_fw(uncore, RING_TAIL(base), 0);
> + intel_uncore_posting_read_fw(uncore, RING_TAIL(base));
>
> /* The ring must be empty before it is disabled */
> - I915_WRITE_FW(RING_CTL(base), 0);
> + intel_uncore_write_fw(uncore, RING_CTL(base), 0);
>
> /* Check acts as a post */
> - if (I915_READ_FW(RING_HEAD(base)))
> + if (intel_uncore_read_fw(uncore, RING_HEAD(base)))
> GEM_TRACE("%s: ring head [%x] not parked\n",
> - engine->name, I915_READ_FW(RING_HEAD(base)));
> +
Re: [Intel-gfx] [PATCH v2] drm/i915: Convert i915_reset.c over to using uncore mmio
Em sex, 2019-04-05 às 21:24 +0100, Chris Wilson escreveu:
> Currently i915_reset.c mixes calls to intel_uncore, pci and our old
> style I915_READ mmio interfaces. Cast aside the old implicit macros,
> and harmonise on using uncore throughout.
>
> add/remove: 1/1 grow/shrink: 0/4 up/down: 65/-207 (-142)
> Function old new delta
> rmw_register - 65 +65
> gen8_reset_engines 945 942 -3
> g4x_do_reset 407 376 -31
> intel_gpu_reset 545 509 -36
> clear_register63 - -63
> i915_clear_error_registers 461 387 -74
>
> A little bit of pointer dancing elimination works wonders.
>
> v2: Roll up the helpers into intel_uncore for general use
>
> With the helpers gcc was a little more eager to inline:
> add/remove: 0/1 grow/shrink: 1/3 up/down: 99/-133 (-34)
> Function old new delta
> i915_clear_error_registers 461 560 +99
> gen8_reset_engines 945 942 -3
> g4x_do_reset 407 376 -31
> intel_gpu_reset 545 509 -36
> clear_register63 - -63
> Total: Before=1544400, After=1544366, chg -0.00%
>
> Win some, lose some, gcc is gcc.
>
> Signed-off-by: Chris Wilson
> Cc: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reset.c | 122
> drivers/gpu/drm/i915/intel_uncore.h | 23 +-
> 2 files changed, 89 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reset.c
> b/drivers/gpu/drm/i915/i915_reset.c
> index d44dc8422e8c..ac168de6a66e 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -18,6 +18,26 @@
> /* XXX How to handle concurrent GGTT updates using tiling registers? */
> #define RESET_UNDER_STOP_MACHINE 0
>
> +static void rmw_set(struct intel_uncore *uncore, i915_reg_t reg, u32 set)
> +{
> + intel_uncore_rmw(uncore, reg, 0, set);
> +}
> +
> +static void rmw_clear(struct intel_uncore *uncore, i915_reg_t reg, u32 clr)
> +{
> + intel_uncore_rmw(uncore, reg, clr, 0);
> +}
> +
> +static void rwm_set_fw(struct intel_uncore *uncore, i915_reg_t reg, u32 set)
We're not reading, writing and then modifying :).
> +{
> + intel_uncore_rmw_fw(uncore, reg, 0, set);
> +}
> +
> +static void rmw_clear_fw(struct intel_uncore *uncore, i915_reg_t reg, u32
> clr)
> +{
> + intel_uncore_rmw_fw(uncore, reg, clr, 0);
> +}
> +
> static void engine_skip_context(struct i915_request *rq)
> {
> struct intel_engine_cs *engine = rq->engine;
> @@ -119,7 +139,7 @@ void i915_reset_request(struct i915_request *rq, bool
> guilty)
>
> static void gen3_stop_engine(struct intel_engine_cs *engine)
> {
> - struct drm_i915_private *dev_priv = engine->i915;
> + struct intel_uncore *uncore = engine->uncore;
> const u32 base = engine->mmio_base;
>
> GEM_TRACE("%s\n", engine->name);
> @@ -127,20 +147,23 @@ static void gen3_stop_engine(struct intel_engine_cs
> *engine)
> if (intel_engine_stop_cs(engine))
> GEM_TRACE("%s: timed out on STOP_RING\n", engine->name);
>
> - I915_WRITE_FW(RING_HEAD(base), I915_READ_FW(RING_TAIL(base)));
> - POSTING_READ_FW(RING_HEAD(base)); /* paranoia */
> + intel_uncore_write_fw(uncore,
> + RING_HEAD(base),
> + intel_uncore_read_fw(uncore, RING_TAIL(base)));
> + intel_uncore_posting_read_fw(uncore, RING_HEAD(base)); /* paranoia */
>
> - I915_WRITE_FW(RING_HEAD(base), 0);
> - I915_WRITE_FW(RING_TAIL(base), 0);
> - POSTING_READ_FW(RING_TAIL(base));
> + intel_uncore_write_fw(uncore, RING_HEAD(base), 0);
> + intel_uncore_write_fw(uncore, RING_TAIL(base), 0);
> + intel_uncore_posting_read_fw(uncore, RING_TAIL(base));
>
> /* The ring must be empty before it is disabled */
> - I915_WRITE_FW(RING_CTL(base), 0);
> + intel_uncore_write_fw(uncore, RING_CTL(base), 0);
>
> /* Check acts as a post */
> - if (I915_READ_FW(RING_HEAD(base)))
> + if (intel_uncore_read_fw(uncore, RING_HEAD(base)))
> GEM_TRACE("%s: ring head [%x] not parked\n",
> - engine->name, I915_READ_FW(RING_HEAD(base)));
> +
[Intel-gfx] [PATCH 2/3] drm/i915: convert the IRQ initialization functions to intel_uncore
The IRQ initialization helpers are simple and self-contained. Continue
the transition started in the recent uncore rework to get us rid of
I915_READ/WRITE and the implicit dev_priv variables.
While the implicit dev_priv is removed from the IRQ initialization
helpers, we didn't get rid of them in the macro callers. Doing that
should be very simple now.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 100
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a1e7944fb5d0..99a6527568cf 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,115 +136,115 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
};
-static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+static void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
i915_reg_t iir, i915_reg_t ier)
{
- I915_WRITE(imr, 0x);
- POSTING_READ(imr);
+ intel_uncore_write(uncore, imr, 0x);
+ intel_uncore_posting_read(uncore, imr);
- I915_WRITE(ier, 0);
+ intel_uncore_write(uncore, ier, 0);
/* IIR can theoretically queue up two events. Be paranoid. */
- I915_WRITE(iir, 0x);
- POSTING_READ(iir);
- I915_WRITE(iir, 0x);
- POSTING_READ(iir);
+ intel_uncore_write(uncore, iir, 0x);
+ intel_uncore_posting_read(uncore, iir);
+ intel_uncore_write(uncore, iir, 0x);
+ intel_uncore_posting_read(uncore, iir);
}
-static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+static void gen2_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
i915_reg_t iir, i915_reg_t ier)
{
- I915_WRITE16(imr, 0x);
- POSTING_READ16(imr);
+ intel_uncore_write16(uncore, imr, 0x);
+ intel_uncore_posting_read16(uncore, imr);
- I915_WRITE16(ier, 0);
+ intel_uncore_write16(uncore, ier, 0);
/* IIR can theoretically queue up two events. Be paranoid. */
- I915_WRITE16(iir, 0x);
- POSTING_READ16(iir);
- I915_WRITE16(iir, 0x);
- POSTING_READ16(iir);
+ intel_uncore_write16(uncore, iir, 0x);
+ intel_uncore_posting_read16(uncore, iir);
+ intel_uncore_write16(uncore, iir, 0x);
+ intel_uncore_posting_read16(uncore, iir);
}
#define GEN8_IRQ_RESET_NDX(type, which) \
- gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \
+ gen3_irq_reset(&dev_priv->uncore, GEN8_##type##_IMR(which), \
GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
#define GEN3_IRQ_RESET(type) \
- gen3_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
+ gen3_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
#define GEN2_IRQ_RESET(type) \
- gen2_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
+ gen2_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
/*
* We should clear IMR at preinstall/uninstall, and just check at postinstall.
*/
-static void gen3_assert_iir_is_zero(struct drm_i915_private *dev_priv,
+static void gen3_assert_iir_is_zero(struct intel_uncore *uncore,
i915_reg_t reg)
{
- u32 val = I915_READ(reg);
+ u32 val = intel_uncore_read(uncore, reg);
if (val == 0)
return;
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
i915_mmio_reg_offset(reg), val);
- I915_WRITE(reg, 0x);
- POSTING_READ(reg);
- I915_WRITE(reg, 0x);
- POSTING_READ(reg);
+ intel_uncore_write(uncore, reg, 0x);
+ intel_uncore_posting_read(uncore, reg);
+ intel_uncore_write(uncore, reg, 0x);
+ intel_uncore_posting_read(uncore, reg);
}
-static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv,
+static void gen2_assert_iir_is_zero(struct intel_uncore *uncore,
i915_reg_t reg)
{
- u16 val = I915_READ16(reg);
+ u16 val = intel_uncore_read16(uncore, reg);
if (val == 0)
return;
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
i915_mmio_reg_offset(reg), val);
- I915_WRITE16(reg, 0x);
- POSTING_READ16(reg);
- I915_WRITE16(reg, 0x);
- POSTING_READ16(reg);
+ intel_uncore_write16(uncore, reg, 0x);
+ intel_uncore_posting_read16(uncore, reg);
+ intel_uncore_write16(uncore, reg, 0x);
+ intel_uncore_posting_read16(uncore, reg);
}
-static void gen3_irq_init(struct drm_i915_private *dev_priv, i915_reg_t imr,
+static void gen3_irq_init(struct intel_uncore *uncore, i915_reg_t imr,
[Intel-gfx] [PATCH 0/3] IRQ initialization debloat and conversion to uncore
The first patch is a simple refactor to try to debloat our IRQ initialization and the second is a tiny conversion to the new intel_uncore model. I'm not sure how much we want patch 3 right now, but my understanding is that we want to move in that direction anyway, so why not now. Cc: Daniele Ceraolo Spurio Paulo Zanoni (3): drm/i915: refactor the IRQ init/reset macros drm/i915: convert the IRQ initialization functions to intel_uncore drm/i915: fully convert the IRQ initialization macros to intel_uncore drivers/gpu/drm/i915/i915_irq.c | 275 +++- 1 file changed, 165 insertions(+), 110 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: refactor the IRQ init/reset macros
The whole point of having macros here is for the token pasting
necessary to automatically have IMR, IIR and IER selected. We don't
really need or want all the inlining that happens as a consequence.
The good thing about the current code is that it works regardless of
the relative offsets between these registers (they change after gen3).
One thing which we can do is to split the logic of what we do with
imr/ier/iir to functions separate from the macros that pick them.
That's what we do in this commit. This allows us to get rid of the
gen8 duplicates and also all the inlining:
add/remove: 2/0 grow/shrink: 0/21 up/down: 383/-6006 (-5623)
Function old new delta
gen3_irq_reset - 233+233
gen3_irq_init - 150+150
i8xx_irq_postinstall 459 442 -17
gen11_irq_postinstall804 744 -60
ironlake_irq_postinstall 450 353 -97
vlv_display_irq_postinstall 348 245-103
i965_irq_postinstall 378 275-103
i915_irq_postinstall 333 228-105
gen8_irq_power_well_post_enable 374 210-164
ironlake_irq_reset 397 218-179
vlv_display_irq_reset616 433-183
i965_irq_reset 374 180-194
cherryview_irq_reset 379 185-194
i915_irq_reset 407 209-198
ibx_irq_reset332 133-199
gen5_gt_irq_postinstall 533 332-201
gen8_irq_power_well_pre_disable 434 204-230
gen8_gt_irq_postinstall 469 196-273
gen8_de_irq_postinstall 1200 805-395
gen5_gt_irq_reset471 76-395
gen8_gt_irq_reset775 99-676
gen8_irq_reset 1100 333-767
gen11_irq_reset 1959 686 -1273
Total: Before=2262051, After=2256428, chg -0.25%
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 123 +++-
1 file changed, 73 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6454ddc37f8b..a1e7944fb5d0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,36 +136,45 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
};
-/* IIR can theoretically queue up two events. Be paranoid. */
-#define GEN8_IRQ_RESET_NDX(type, which) do { \
- I915_WRITE(GEN8_##type##_IMR(which), 0x); \
- POSTING_READ(GEN8_##type##_IMR(which)); \
- I915_WRITE(GEN8_##type##_IER(which), 0); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- POSTING_READ(GEN8_##type##_IIR(which)); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- POSTING_READ(GEN8_##type##_IIR(which)); \
-} while (0)
-
-#define GEN3_IRQ_RESET(type) do { \
- I915_WRITE(type##IMR, 0x); \
- POSTING_READ(type##IMR); \
- I915_WRITE(type##IER, 0); \
- I915_WRITE(type##IIR, 0x); \
- POSTING_READ(type##IIR); \
- I915_WRITE(type##IIR, 0x); \
- POSTING_READ(type##IIR); \
-} while (0)
-
-#define GEN2_IRQ_RESET(type) do { \
- I915_WRITE16(type##IMR, 0x); \
- POSTING_READ16(type##IMR); \
- I915_WRITE16(type##IER, 0); \
- I915_WRITE16(type##IIR, 0x); \
- POSTING_READ16(type##IIR); \
- I915_WRITE16(type##IIR, 0x); \
- POSTING_READ16(type##IIR); \
-} while (0)
+static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+ i915_reg_t iir, i915_reg_t ier)
+{
+ I915_WRITE(imr, 0x);
+ POSTING_READ(imr);
+
+ I915_WRITE(ier, 0);
+
+ /* IIR can theoretically queue up two events. Be paranoid. */
+ I915_WRITE(iir, 0x);
+ POSTING_READ(iir);
+ I915_WRITE(iir, 0x);
+ POSTING_READ(iir);
+}
+
+static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+ i915_reg_t iir, i915_reg_t ier)
+{
+ I915_WRITE16(imr, 0x);
+ POSTING_READ16(imr);
+
+ I915_WRITE16(ier, 0);
+
+ /* IIR can theoretically queue up two events. Be paranoid. */
+ I915_WRITE16(iir, 0x);
+ POSTING_READ16(iir);
+ I915_WRITE16(iir, 0x);
+ POSTING_READ16(iir);
+}
+
+#define GEN8_IRQ_RESET_NDX(type, which) \
+ gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \
+ GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
+
+#define GEN3_IRQ_
[Intel-gfx] [PATCH 3/3] drm/i915: fully convert the IRQ initialization macros to intel_uncore
Make them take the uncore argument from the caller instead of passing
the implicit &dev_priv->uncore directly. This will allow us to finally
pass something that's not dev_priv->uncore in the future, and gets rid
of the implicit variables in register macros.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 144 +++-
1 file changed, 88 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 99a6527568cf..b6361bab1086 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -166,15 +166,15 @@ static void gen2_irq_reset(struct intel_uncore *uncore,
i915_reg_t imr,
intel_uncore_posting_read16(uncore, iir);
}
-#define GEN8_IRQ_RESET_NDX(type, which) \
- gen3_irq_reset(&dev_priv->uncore, GEN8_##type##_IMR(which), \
+#define GEN8_IRQ_RESET_NDX(uncore, type, which) \
+ gen3_irq_reset((uncore), GEN8_##type##_IMR(which), \
GEN8_##type##_IIR(which), GEN8_##type##_IER(which))
-#define GEN3_IRQ_RESET(type) \
- gen3_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
+#define GEN3_IRQ_RESET(uncore, type) \
+ gen3_irq_reset((uncore), type##IMR, type##IIR, type##IER)
-#define GEN2_IRQ_RESET(type) \
- gen2_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
+#define GEN2_IRQ_RESET(uncore, type) \
+ gen2_irq_reset((uncore), type##IMR, type##IIR, type##IER)
/*
* We should clear IMR at preinstall/uninstall, and just check at postinstall.
@@ -233,17 +233,17 @@ static void gen2_irq_init(struct intel_uncore *uncore,
i915_reg_t imr,
intel_uncore_posting_read16(uncore, imr);
}
-#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
- gen3_irq_init(&dev_priv->uncore, GEN8_##type##_IMR(which), \
+#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \
+ gen3_irq_init((uncore), GEN8_##type##_IMR(which), \
GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \
imr_val, ier_val)
-#define GEN3_IRQ_INIT(type, imr_val, ier_val) \
- gen3_irq_init(&dev_priv->uncore, type##IMR, type##IIR, type##IER, \
+#define GEN3_IRQ_INIT(uncore, type, imr_val, ier_val) \
+ gen3_irq_init((uncore), type##IMR, type##IIR, type##IER, \
imr_val, ier_val)
-#define GEN2_IRQ_INIT(type, imr_val, ier_val) \
- gen2_irq_init(&dev_priv->uncore, type##IMR, type##IIR, type##IER, \
+#define GEN2_IRQ_INIT(uncore, type, imr_val, ier_val) \
+ gen2_irq_init((uncore), type##IMR, type##IIR, type##IER, \
imr_val, ier_val)
static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir);
@@ -3331,10 +3331,12 @@ static void i945gm_vblank_work_fini(struct
drm_i915_private *dev_priv)
static void ibx_irq_reset(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = &dev_priv->uncore;
+
if (HAS_PCH_NOP(dev_priv))
return;
- GEN3_IRQ_RESET(SDE);
+ GEN3_IRQ_RESET(uncore, SDE);
if (HAS_PCH_CPT(dev_priv) || HAS_PCH_LPT(dev_priv))
I915_WRITE(SERR_INT, 0x);
@@ -3362,13 +3364,17 @@ static void ibx_irq_pre_postinstall(struct drm_device
*dev)
static void gen5_gt_irq_reset(struct drm_i915_private *dev_priv)
{
- GEN3_IRQ_RESET(GT);
+ struct intel_uncore *uncore = &dev_priv->uncore;
+
+ GEN3_IRQ_RESET(uncore, GT);
if (INTEL_GEN(dev_priv) >= 6)
- GEN3_IRQ_RESET(GEN6_PM);
+ GEN3_IRQ_RESET(uncore, GEN6_PM);
}
static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = &dev_priv->uncore;
+
if (IS_CHERRYVIEW(dev_priv))
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
else
@@ -3379,12 +3385,14 @@ static void vlv_display_irq_reset(struct
drm_i915_private *dev_priv)
i9xx_pipestat_irq_reset(dev_priv);
- GEN3_IRQ_RESET(VLV_);
+ GEN3_IRQ_RESET(uncore, VLV_);
dev_priv->irq_mask = ~0u;
}
static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = &dev_priv->uncore;
+
u32 pipestat_mask;
u32 enable_mask;
enum pipe pipe;
@@ -3409,7 +3417,7 @@ static void vlv_display_irq_postinstall(struct
drm_i915_private *dev_priv)
dev_priv->irq_mask = ~enable_mask;
- GEN3_IRQ_INIT(VLV_, dev_priv->irq_mask, enable_mask);
+ GEN3_IRQ_INIT(uncore, VLV_, dev_priv->irq_mask, enable_mask);
}
/* drm_dma.h hooks
@@ -3417,8 +3425,9 @@ static void vlv_display_irq_postinstall(struct
drm_i915_private *dev_priv)
static void ironlake_irq_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_uncore *unco
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for IRQ initialization debloat and conversion to uncore
Em ter, 2019-04-09 às 00:44 +, Patchwork escreveu: > == Series Details == > > Series: IRQ initialization debloat and conversion to uncore > URL : https://patchwork.freedesktop.org/series/59202/ > State : warning > > == Summary == > > $ dim checkpatch origin/drm-tip > 7f73d1fe31bb drm/i915: refactor the IRQ init/reset macros > -:114: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > side-effects? > #114: FILE: drivers/gpu/drm/i915/i915_irq.c:169: > +#define GEN8_IRQ_RESET_NDX(type, which) \ > + gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \ > +GEN8_##type##_IIR(which), GEN8_##type##_IER(which)) > > -:172: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > side-effects? > #172: FILE: drivers/gpu/drm/i915/i915_irq.c:236: > +#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \ > + gen3_irq_init(dev_priv, GEN8_##type##_IMR(which), \ > + GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \ > + imr_val, ier_val) > > total: 0 errors, 0 warnings, 2 checks, 135 lines checked > 82160241d80f drm/i915: convert the IRQ initialization functions to > intel_uncore > 8c1c76059a41 drm/i915: fully convert the IRQ initialization macros to > intel_uncore > -:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > side-effects? > #24: FILE: drivers/gpu/drm/i915/i915_irq.c:169: > +#define GEN8_IRQ_RESET_NDX(uncore, type, which) \ > + gen3_irq_reset((uncore), GEN8_##type##_IMR(which), \ > GEN8_##type##_IIR(which), GEN8_##type##_IER(which)) > > -:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > side-effects? > #46: FILE: drivers/gpu/drm/i915/i915_irq.c:236: > +#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \ > + gen3_irq_init((uncore), GEN8_##type##_IMR(which), \ > GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \ > imr_val, ier_val) The whiches are not really a regression, but OK we can deal with them to make the robots happy. > > -:401: ERROR:SPACING: space prohibited before that close parenthesis ')' > #401: FILE: drivers/gpu/drm/i915/i915_irq.c:4228: > + GEN2_IRQ_RESET(uncore, ); > > -:416: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > #416: FILE: drivers/gpu/drm/i915/i915_irq.c:4252: > + GEN2_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > ^ > > -:433: ERROR:SPACING: space prohibited before that close parenthesis ')' > #433: FILE: drivers/gpu/drm/i915/i915_irq.c:4397: > + GEN3_IRQ_RESET(uncore, ); > > -:448: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > #448: FILE: drivers/gpu/drm/i915/i915_irq.c:4430: > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > ^ > > -:464: ERROR:SPACING: space prohibited before that close parenthesis ')' > #464: FILE: drivers/gpu/drm/i915/i915_irq.c:4508: > + GEN3_IRQ_RESET(uncore, ); > > -:479: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > #479: FILE: drivers/gpu/drm/i915/i915_irq.c:4552: > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); For these ones I really think the spaces help. I would love to read some opinions. Perhaps some comment like /* paste token here */ would help make the code more readable and could help silence checkpatch. Opinions? > ^ > > total: 6 errors, 0 warnings, 2 checks, 432 lines checked > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: refactor the IRQ init/reset macros
Em ter, 2019-04-09 às 21:10 +0300, Ville Syrjälä escreveu:
> On Mon, Apr 08, 2019 at 05:37:27PM -0700, Paulo Zanoni wrote:
> > The whole point of having macros here is for the token pasting
> > necessary to automatically have IMR, IIR and IER selected. We don't
> > really need or want all the inlining that happens as a consequence.
> > The good thing about the current code is that it works regardless of
> > the relative offsets between these registers (they change after gen3).
>
> Did you mean "after gen4"? The DE/GT split happened at ilk, and I
> guess that's when the four registers also got reshuffled for some
> reason. Ignoring the funkyness of vlv/chv or course :)
>
You're right. I'll fix the commit message.
> > One thing which we can do is to split the logic of what we do with
> > imr/ier/iir to functions separate from the macros that pick them.
> > That's what we do in this commit. This allows us to get rid of the
> > gen8 duplicates and also all the inlining:
> >
> > add/remove: 2/0 grow/shrink: 0/21 up/down: 383/-6006 (-5623)
> > Function old new delta
> > gen3_irq_reset - 233+233
> > gen3_irq_init - 150+150
> > i8xx_irq_postinstall 459 442 -17
> > gen11_irq_postinstall804 744 -60
> > ironlake_irq_postinstall 450 353 -97
> > vlv_display_irq_postinstall 348 245-103
> > i965_irq_postinstall 378 275-103
> > i915_irq_postinstall 333 228-105
> > gen8_irq_power_well_post_enable 374 210-164
> > ironlake_irq_reset 397 218-179
> > vlv_display_irq_reset616 433-183
> > i965_irq_reset 374 180-194
> > cherryview_irq_reset 379 185-194
> > i915_irq_reset 407 209-198
> > ibx_irq_reset332 133-199
> > gen5_gt_irq_postinstall 533 332-201
> > gen8_irq_power_well_pre_disable 434 204-230
> > gen8_gt_irq_postinstall 469 196-273
> > gen8_de_irq_postinstall 1200 805-395
> > gen5_gt_irq_reset471 76-395
> > gen8_gt_irq_reset 775 99-676
> > gen8_irq_reset 1100 333-767
> > gen11_irq_reset 1959 686 -1273
> > Total: Before=2262051, After=2256428, chg -0.25%
> >
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 123 +++-
> > 1 file changed, 73 insertions(+), 50 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 6454ddc37f8b..a1e7944fb5d0 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -136,36 +136,45 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
> > [HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
> > };
> >
> > -/* IIR can theoretically queue up two events. Be paranoid. */
> > -#define GEN8_IRQ_RESET_NDX(type, which) do { \
> > - I915_WRITE(GEN8_##type##_IMR(which), 0x); \
> > - POSTING_READ(GEN8_##type##_IMR(which)); \
> > - I915_WRITE(GEN8_##type##_IER(which), 0); \
> > - I915_WRITE(GEN8_##type##_IIR(which), 0x); \
> > - POSTING_READ(GEN8_##type##_IIR(which)); \
> > - I915_WRITE(GEN8_##type##_IIR(which), 0x); \
> > - POSTING_READ(GEN8_##type##_IIR(which)); \
> > -} while (0)
> > -
> > -#define GEN3_IRQ_RESET(type) do { \
> > - I915_WRITE(type##IMR, 0x); \
> > - POSTING_READ(type##IMR); \
> > - I915_WRITE(type##IER, 0); \
> > - I915_WRITE(type##IIR, 0x); \
> > - POSTING_READ(type##IIR); \
> > - I915_WRITE(type##IIR, 0x); \
> > - POSTING_READ(type##IIR); \
> > -} while (0)
> > -
> > -#define GEN2_IRQ_RESET(type) do { \
> > - I915_WRITE16(type##IMR, 0x); \
> > - POSTING_READ16(type##IMR); \
> > - I915_WRITE16(type##IER, 0); \
> > - I915_WRITE16(type##IIR, 0x); \
> > - POSTING_READ16(type##IIR); \
> > - I915_WRITE16(type##IIR, 0x); \
> > - POSTING_READ16(type#
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for IRQ initialization debloat and conversion to uncore
Em ter, 2019-04-09 às 21:20 +0300, Ville Syrjälä escreveu: > On Tue, Apr 09, 2019 at 10:34:22AM -0700, Paulo Zanoni wrote: > > Em ter, 2019-04-09 às 00:44 +, Patchwork escreveu: > > > == Series Details == > > > > > > Series: IRQ initialization debloat and conversion to uncore > > > URL : https://patchwork.freedesktop.org/series/59202/ > > > State : warning > > > > > > == Summary == > > > > > > $ dim checkpatch origin/drm-tip > > > 7f73d1fe31bb drm/i915: refactor the IRQ init/reset macros > > > -:114: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > > side-effects? > > > #114: FILE: drivers/gpu/drm/i915/i915_irq.c:169: > > > +#define GEN8_IRQ_RESET_NDX(type, which) \ > > > + gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which), \ > > > +GEN8_##type##_IIR(which), GEN8_##type##_IER(which)) > > > > > > -:172: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > > side-effects? > > > #172: FILE: drivers/gpu/drm/i915/i915_irq.c:236: > > > +#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \ > > > + gen3_irq_init(dev_priv, GEN8_##type##_IMR(which), \ > > > + GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \ > > > + imr_val, ier_val) > > > > > > total: 0 errors, 0 warnings, 2 checks, 135 lines checked > > > 82160241d80f drm/i915: convert the IRQ initialization functions to > > > intel_uncore > > > 8c1c76059a41 drm/i915: fully convert the IRQ initialization macros to > > > intel_uncore > > > -:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > > side-effects? > > > #24: FILE: drivers/gpu/drm/i915/i915_irq.c:169: > > > +#define GEN8_IRQ_RESET_NDX(uncore, type, which) \ > > > + gen3_irq_reset((uncore), GEN8_##type##_IMR(which), \ > > > GEN8_##type##_IIR(which), GEN8_##type##_IER(which)) > > > > > > -:46: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'which' - possible > > > side-effects? > > > #46: FILE: drivers/gpu/drm/i915/i915_irq.c:236: > > > +#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \ > > > + gen3_irq_init((uncore), GEN8_##type##_IMR(which), \ > > > GEN8_##type##_IIR(which), GEN8_##type##_IER(which), \ > > > imr_val, ier_val) > > > > The whiches are not really a regression, but OK we can deal with them > > to make the robots happy. > > > > > -:401: ERROR:SPACING: space prohibited before that close parenthesis ')' > > > #401: FILE: drivers/gpu/drm/i915/i915_irq.c:4228: > > > + GEN2_IRQ_RESET(uncore, ); > > > > > > -:416: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > > > #416: FILE: drivers/gpu/drm/i915/i915_irq.c:4252: > > > + GEN2_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > > > ^ > > > > > > -:433: ERROR:SPACING: space prohibited before that close parenthesis ')' > > > #433: FILE: drivers/gpu/drm/i915/i915_irq.c:4397: > > > + GEN3_IRQ_RESET(uncore, ); > > > > > > -:448: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > > > #448: FILE: drivers/gpu/drm/i915/i915_irq.c:4430: > > > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > > > ^ > > > > > > -:464: ERROR:SPACING: space prohibited before that close parenthesis ')' > > > #464: FILE: drivers/gpu/drm/i915/i915_irq.c:4508: > > > + GEN3_IRQ_RESET(uncore, ); > > > > > > -:479: ERROR:SPACING: space prohibited before that ',' (ctx:WxW) > > > #479: FILE: drivers/gpu/drm/i915/i915_irq.c:4552: > > > + GEN3_IRQ_INIT(uncore, , dev_priv->irq_mask, enable_mask); > > > > For these ones I really think the spaces help. I would love to read > > some opinions. Perhaps some comment like /* paste token here */ would > > help make the code more readable and could help silence checkpatch. > > Opinions? > > Or maybe rename the registers to eg. I9XX_IIR? That makes more sense. We use these regs on gen2 too, so I suppose I8XX_IIR (or GEN2_IIR) would make more sense. OTOH it would break our current naming rule. I'll submit v2 soon. Thanks. > > > > ^ > > > > > > total: 6 errors, 0 warnings, 2 checks, 432 lines checked > > > > > > ___ > > > 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 > > -- > Ville Syrjälä > Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] IRQ initialization debloat and conversion to uncore, v2
The first patch is a simple refactor to try to debloat our IRQ
initialization and the last ones are a tiny conversion to the new
intel_uncore model. I'm not sure how much we want patch 5 right now,
but my understanding is that we want to move in that direction anyway,
so why not now.
New in v2:
- Two additional patches based on the discussion with Ville and Checkpatch.
- No more checkpatch complaints.
Cc: Ville Syrjälä
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
Paulo Zanoni (5):
drm/i915: refactor the IRQ init/reset macros
drm/i915: don't specify the IRQ register in the gen2 macros
drm/i915: add GEN2_ prefix to the I{E,I,M,S}R registers
drm/i915: convert the IRQ initialization functions to intel_uncore
drm/i915: fully convert the IRQ initialization macros to intel_uncore
drivers/gpu/drm/i915/i915_debugfs.c | 6 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 298 ++--
drivers/gpu/drm/i915/i915_reg.h | 8 +-
drivers/gpu/drm/i915/i915_reset.c | 3 +-
drivers/gpu/drm/i915/intel_overlay.c| 4 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
7 files changed, 197 insertions(+), 136 deletions(-)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: don't specify the IRQ register in the gen2 macros
Like the gen3+ macros, the gen2 versions of the IRQ initialization
macros take the register name in the 'type' argument. But gen2 only
has one set of registers, so there's really no need to specify the
type. This commit removes the type argument and uses the registers
directly instead of passing them through variables.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 57 +++--
1 file changed, 25 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 60a3f4203ac3..b1f1db2bd879 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -151,19 +151,18 @@ static void gen3_irq_reset(struct drm_i915_private
*dev_priv, i915_reg_t imr,
POSTING_READ(iir);
}
-static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
- i915_reg_t iir, i915_reg_t ier)
+static void gen2_irq_reset(struct drm_i915_private *dev_priv)
{
- I915_WRITE16(imr, 0x);
- POSTING_READ16(imr);
+ I915_WRITE16(IMR, 0x);
+ POSTING_READ16(IMR);
- I915_WRITE16(ier, 0);
+ I915_WRITE16(IER, 0);
/* IIR can theoretically queue up two events. Be paranoid. */
- I915_WRITE16(iir, 0x);
- POSTING_READ16(iir);
- I915_WRITE16(iir, 0x);
- POSTING_READ16(iir);
+ I915_WRITE16(IIR, 0x);
+ POSTING_READ16(IIR);
+ I915_WRITE16(IIR, 0x);
+ POSTING_READ16(IIR);
}
#define GEN8_IRQ_RESET_NDX(type, which) \
@@ -176,8 +175,8 @@ static void gen2_irq_reset(struct drm_i915_private
*dev_priv, i915_reg_t imr,
#define GEN3_IRQ_RESET(type) \
gen3_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
-#define GEN2_IRQ_RESET(type) \
- gen2_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
+#define GEN2_IRQ_RESET() \
+ gen2_irq_reset(dev_priv)
/*
* We should clear IMR at preinstall/uninstall, and just check at postinstall.
@@ -198,20 +197,19 @@ static void gen3_assert_iir_is_zero(struct
drm_i915_private *dev_priv,
POSTING_READ(reg);
}
-static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv,
- i915_reg_t reg)
+static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv)
{
- u16 val = I915_READ16(reg);
+ u16 val = I915_READ16(IIR);
if (val == 0)
return;
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
-i915_mmio_reg_offset(reg), val);
- I915_WRITE16(reg, 0x);
- POSTING_READ16(reg);
- I915_WRITE16(reg, 0x);
- POSTING_READ16(reg);
+i915_mmio_reg_offset(IIR), val);
+ I915_WRITE16(IIR, 0x);
+ POSTING_READ16(IIR);
+ I915_WRITE16(IIR, 0x);
+ POSTING_READ16(IIR);
}
static void gen3_irq_init(struct drm_i915_private *dev_priv,
@@ -227,15 +225,13 @@ static void gen3_irq_init(struct drm_i915_private
*dev_priv,
}
static void gen2_irq_init(struct drm_i915_private *dev_priv,
- i915_reg_t imr, u32 imr_val,
- i915_reg_t ier, u32 ier_val,
- i915_reg_t iir)
+ u32 imr_val, u32 ier_val)
{
- gen2_assert_iir_is_zero(dev_priv, iir);
+ gen2_assert_iir_is_zero(dev_priv);
- I915_WRITE16(ier, ier_val);
- I915_WRITE16(imr, imr_val);
- POSTING_READ16(imr);
+ I915_WRITE16(IER, ier_val);
+ I915_WRITE16(IMR, imr_val);
+ POSTING_READ16(IMR);
}
#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
@@ -253,11 +249,8 @@ static void gen2_irq_init(struct drm_i915_private
*dev_priv,
type##IER, ier_val, \
type##IIR)
-#define GEN2_IRQ_INIT(type, imr_val, ier_val) \
- gen2_irq_init(dev_priv, \
- type##IMR, imr_val, \
- type##IER, ier_val, \
- type##IIR)
+#define GEN2_IRQ_INIT(imr_val, ier_val) \
+ gen2_irq_init(dev_priv, imr_val, ier_val)
static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir);
static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir);
@@ -4247,7 +4240,7 @@ static int i8xx_irq_postinstall(struct drm_device *dev)
I915_MASTER_ERROR_INTERRUPT |
I915_USER_INTERRUPT;
- GEN2_IRQ_INIT(, dev_priv->irq_mask, enable_mask);
+ GEN2_IRQ_INIT(dev_priv->irq_mask, enable_mask);
/* Interrupt setup is already guaranteed to be single-threaded, this is
* just to make the assert_spin_locked check happy. */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: fully convert the IRQ initialization macros to intel_uncore
Make them take the uncore argument from the caller instead of passing
the implicit &dev_priv->uncore directly. This will allow us to finally
pass something that's not dev_priv->uncore in the future, and gets rid
of the implicit variables in register macros.
v2: Rebase on top of the newer patches.
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 144 +++-
1 file changed, 88 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 22b89da25289..f6ab4c4c6388 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -165,18 +165,18 @@ static void gen2_irq_reset(struct intel_uncore *uncore)
intel_uncore_posting_read16(uncore, GEN2_IIR);
}
-#define GEN8_IRQ_RESET_NDX(type, which) \
+#define GEN8_IRQ_RESET_NDX(uncore, type, which) \
({ \
unsigned int which_ = which; \
- gen3_irq_reset(&dev_priv->uncore, GEN8_##type##_IMR(which_), \
+ gen3_irq_reset((uncore), GEN8_##type##_IMR(which_), \
GEN8_##type##_IIR(which_), GEN8_##type##_IER(which_)); \
})
-#define GEN3_IRQ_RESET(type) \
- gen3_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
+#define GEN3_IRQ_RESET(uncore, type) \
+ gen3_irq_reset((uncore), type##IMR, type##IIR, type##IER)
-#define GEN2_IRQ_RESET() \
- gen2_irq_reset(&dev_priv->uncore)
+#define GEN2_IRQ_RESET(uncore) \
+ gen2_irq_reset(uncore)
/*
* We should clear IMR at preinstall/uninstall, and just check at postinstall.
@@ -233,23 +233,23 @@ static void gen2_irq_init(struct intel_uncore *uncore,
intel_uncore_posting_read16(uncore, GEN2_IMR);
}
-#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) \
+#define GEN8_IRQ_INIT_NDX(uncore, type, which, imr_val, ier_val) \
({ \
unsigned int which_ = which; \
- gen3_irq_init(&dev_priv->uncore, \
+ gen3_irq_init((uncore), \
GEN8_##type##_IMR(which_), imr_val, \
GEN8_##type##_IER(which_), ier_val, \
GEN8_##type##_IIR(which_)); \
})
-#define GEN3_IRQ_INIT(type, imr_val, ier_val) \
- gen3_irq_init(&dev_priv->uncore, \
+#define GEN3_IRQ_INIT(uncore, type, imr_val, ier_val) \
+ gen3_irq_init((uncore), \
type##IMR, imr_val, \
type##IER, ier_val, \
type##IIR)
-#define GEN2_IRQ_INIT(imr_val, ier_val) \
- gen2_irq_init(&dev_priv->uncore, imr_val, ier_val)
+#define GEN2_IRQ_INIT(uncore, imr_val, ier_val) \
+ gen2_irq_init((uncore), imr_val, ier_val)
static void gen6_rps_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir);
static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32
pm_iir);
@@ -3349,10 +3349,12 @@ static void i945gm_vblank_work_fini(struct
drm_i915_private *dev_priv)
static void ibx_irq_reset(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = &dev_priv->uncore;
+
if (HAS_PCH_NOP(dev_priv))
return;
- GEN3_IRQ_RESET(SDE);
+ GEN3_IRQ_RESET(uncore, SDE);
if (HAS_PCH_CPT(dev_priv) || HAS_PCH_LPT(dev_priv))
I915_WRITE(SERR_INT, 0x);
@@ -3380,13 +3382,17 @@ static void ibx_irq_pre_postinstall(struct drm_device
*dev)
static void gen5_gt_irq_reset(struct drm_i915_private *dev_priv)
{
- GEN3_IRQ_RESET(GT);
+ struct intel_uncore *uncore = &dev_priv->uncore;
+
+ GEN3_IRQ_RESET(uncore, GT);
if (INTEL_GEN(dev_priv) >= 6)
- GEN3_IRQ_RESET(GEN6_PM);
+ GEN3_IRQ_RESET(uncore, GEN6_PM);
}
static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = &dev_priv->uncore;
+
if (IS_CHERRYVIEW(dev_priv))
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
else
@@ -3397,12 +3403,14 @@ static void vlv_display_irq_reset(struct
drm_i915_private *dev_priv)
i9xx_pipestat_irq_reset(dev_priv);
- GEN3_IRQ_RESET(VLV_);
+ GEN3_IRQ_RESET(uncore, VLV_);
dev_priv->irq_mask = ~0u;
}
static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
{
+ struct intel_uncore *uncore = &dev_priv->uncore;
+
u32 pipestat_mask;
u32 enable_mask;
enum pipe pipe;
@@ -3427,7 +3435,7 @@ static void vlv_display_irq_postinstall(struct
drm_i915_private *dev_priv)
dev_priv->irq_mask = ~enable_mask;
- GEN3_IRQ_INIT(VLV_, dev_priv->irq_mask, enable_mask);
+ GEN3_IRQ_INIT(uncore, VLV_, dev_priv->irq_mask, enable_mask);
}
/* drm_dma.h hooks
@@ -3435,8 +3443,9 @@ static void vlv_display_irq_postinstall(struct
drm_i915_private *dev_priv)
static void ironlake_irq_reset(struct drm_device *d
[Intel-gfx] [PATCH 3/5] drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registers
This discussion started because we use token pasting in the
GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an
empty argument to those macros, making the code a little weird. The
original proposal was to just add a comment as the empty argument, but
Ville suggested we just add a prefix to the registers, and that indeed
sounds like a more elegant solution.
Now doing this is kinda against our rules for register naming since we
only add gens or platform names as register prefixes when the given
gen/platform changes a register that already existed before. On the
other hand, we have so many instances of IIR/IMR in comments that
adding a prefix would make the users of these register more easily
findable, in addition to make our token pasting macros actually
readable. So IMHO opening an exception here is worth it.
Cc: Ville Syrjälä
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c | 52 -
drivers/gpu/drm/i915/i915_reg.h | 8 ++--
drivers/gpu/drm/i915/i915_reset.c | 3 +-
drivers/gpu/drm/i915/intel_overlay.c| 4 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++---
7 files changed, 44 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 77b3252bdb2e..5823ffb17821 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -833,11 +833,11 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
} else if (!HAS_PCH_SPLIT(dev_priv)) {
seq_printf(m, "Interrupt enable:%08x\n",
- I915_READ(IER));
+ I915_READ(GEN2_IER));
seq_printf(m, "Interrupt identity: %08x\n",
- I915_READ(IIR));
+ I915_READ(GEN2_IIR));
seq_printf(m, "Interrupt mask: %08x\n",
- I915_READ(IMR));
+ I915_READ(GEN2_IMR));
for_each_pipe(dev_priv, pipe)
seq_printf(m, "Pipe %c stat: %08x\n",
pipe_name(pipe),
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 43b68fdc8967..f51ff683dd2e 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1635,9 +1635,9 @@ static void capture_reg_state(struct i915_gpu_state
*error)
error->gtier[0] = I915_READ(GTIER);
error->ngtier = 1;
} else if (IS_GEN(dev_priv, 2)) {
- error->ier = I915_READ16(IER);
+ error->ier = I915_READ16(GEN2_IER);
} else if (!IS_VALLEYVIEW(dev_priv)) {
- error->ier = I915_READ(IER);
+ error->ier = I915_READ(GEN2_IER);
}
error->eir = I915_READ(EIR);
error->pgtbl_er = I915_READ(PGTBL_ER);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1f1db2bd879..2910b06913af 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -153,16 +153,16 @@ static void gen3_irq_reset(struct drm_i915_private
*dev_priv, i915_reg_t imr,
static void gen2_irq_reset(struct drm_i915_private *dev_priv)
{
- I915_WRITE16(IMR, 0x);
- POSTING_READ16(IMR);
+ I915_WRITE16(GEN2_IMR, 0x);
+ POSTING_READ16(GEN2_IMR);
- I915_WRITE16(IER, 0);
+ I915_WRITE16(GEN2_IER, 0);
/* IIR can theoretically queue up two events. Be paranoid. */
- I915_WRITE16(IIR, 0x);
- POSTING_READ16(IIR);
- I915_WRITE16(IIR, 0x);
- POSTING_READ16(IIR);
+ I915_WRITE16(GEN2_IIR, 0x);
+ POSTING_READ16(GEN2_IIR);
+ I915_WRITE16(GEN2_IIR, 0x);
+ POSTING_READ16(GEN2_IIR);
}
#define GEN8_IRQ_RESET_NDX(type, which) \
@@ -199,17 +199,17 @@ static void gen3_assert_iir_is_zero(struct
drm_i915_private *dev_priv,
static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv)
{
- u16 val = I915_READ16(IIR);
+ u16 val = I915_READ16(GEN2_IIR);
if (val == 0)
return;
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
-i915_mmio_reg_offset(IIR), val);
- I915_WRITE16(IIR, 0x);
- POSTING_READ16(IIR);
- I915_WRITE16(IIR, 0x);
- POSTING_READ16(IIR);
+i915_mmio_reg_offset(GEN2_IIR), val);
+ I915_WRITE16(GEN2_IIR, 0x);
+ POSTING_READ16(GEN2_IIR);
+ I915_WRITE16(GEN2_IIR, 0x);
+ POSTING_READ16(GEN2_IIR);
}
static void gen3_irq_init(struct drm_i915_private *dev_priv,
@@ -229,9 +229,9 @@ static void gen2_irq_init(struct drm_i915_private *dev_priv,
{
[Intel-gfx] [PATCH 4/5] drm/i915: convert the IRQ initialization functions to intel_uncore
The IRQ initialization helpers are simple and self-contained. Continue
the transition started in the recent uncore rework to get us rid of
I915_READ/WRITE and the implicit dev_priv variables.
While the implicit dev_priv is removed from the IRQ initialization
helpers, we didn't get rid of them in the macro callers. Doing that
should be very simple now.
v2: Rebase on top of the new patches.
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 97 -
1 file changed, 48 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2910b06913af..22b89da25289 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,121 +136,120 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
};
-static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+static void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
i915_reg_t iir, i915_reg_t ier)
{
- I915_WRITE(imr, 0x);
- POSTING_READ(imr);
+ intel_uncore_write(uncore, imr, 0x);
+ intel_uncore_posting_read(uncore, imr);
- I915_WRITE(ier, 0);
+ intel_uncore_write(uncore, ier, 0);
/* IIR can theoretically queue up two events. Be paranoid. */
- I915_WRITE(iir, 0x);
- POSTING_READ(iir);
- I915_WRITE(iir, 0x);
- POSTING_READ(iir);
+ intel_uncore_write(uncore, iir, 0x);
+ intel_uncore_posting_read(uncore, iir);
+ intel_uncore_write(uncore, iir, 0x);
+ intel_uncore_posting_read(uncore, iir);
}
-static void gen2_irq_reset(struct drm_i915_private *dev_priv)
+static void gen2_irq_reset(struct intel_uncore *uncore)
{
- I915_WRITE16(GEN2_IMR, 0x);
- POSTING_READ16(GEN2_IMR);
+ intel_uncore_write16(uncore, GEN2_IMR, 0x);
+ intel_uncore_posting_read16(uncore, GEN2_IMR);
- I915_WRITE16(GEN2_IER, 0);
+ intel_uncore_write16(uncore, GEN2_IER, 0);
/* IIR can theoretically queue up two events. Be paranoid. */
- I915_WRITE16(GEN2_IIR, 0x);
- POSTING_READ16(GEN2_IIR);
- I915_WRITE16(GEN2_IIR, 0x);
- POSTING_READ16(GEN2_IIR);
+ intel_uncore_write16(uncore, GEN2_IIR, 0x);
+ intel_uncore_posting_read16(uncore, GEN2_IIR);
+ intel_uncore_write16(uncore, GEN2_IIR, 0x);
+ intel_uncore_posting_read16(uncore, GEN2_IIR);
}
#define GEN8_IRQ_RESET_NDX(type, which) \
({ \
unsigned int which_ = which; \
- gen3_irq_reset(dev_priv, GEN8_##type##_IMR(which_), \
+ gen3_irq_reset(&dev_priv->uncore, GEN8_##type##_IMR(which_), \
GEN8_##type##_IIR(which_), GEN8_##type##_IER(which_)); \
})
#define GEN3_IRQ_RESET(type) \
- gen3_irq_reset(dev_priv, type##IMR, type##IIR, type##IER)
+ gen3_irq_reset(&dev_priv->uncore, type##IMR, type##IIR, type##IER)
#define GEN2_IRQ_RESET() \
- gen2_irq_reset(dev_priv)
+ gen2_irq_reset(&dev_priv->uncore)
/*
* We should clear IMR at preinstall/uninstall, and just check at postinstall.
*/
-static void gen3_assert_iir_is_zero(struct drm_i915_private *dev_priv,
- i915_reg_t reg)
+static void gen3_assert_iir_is_zero(struct intel_uncore *uncore, i915_reg_t
reg)
{
- u32 val = I915_READ(reg);
+ u32 val = intel_uncore_read(uncore, reg);
if (val == 0)
return;
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
i915_mmio_reg_offset(reg), val);
- I915_WRITE(reg, 0x);
- POSTING_READ(reg);
- I915_WRITE(reg, 0x);
- POSTING_READ(reg);
+ intel_uncore_write(uncore, reg, 0x);
+ intel_uncore_posting_read(uncore, reg);
+ intel_uncore_write(uncore, reg, 0x);
+ intel_uncore_posting_read(uncore, reg);
}
-static void gen2_assert_iir_is_zero(struct drm_i915_private *dev_priv)
+static void gen2_assert_iir_is_zero(struct intel_uncore *uncore)
{
- u16 val = I915_READ16(GEN2_IIR);
+ u16 val = intel_uncore_read16(uncore, GEN2_IIR);
if (val == 0)
return;
WARN(1, "Interrupt register 0x%x is not zero: 0x%08x\n",
i915_mmio_reg_offset(GEN2_IIR), val);
- I915_WRITE16(GEN2_IIR, 0x);
- POSTING_READ16(GEN2_IIR);
- I915_WRITE16(GEN2_IIR, 0x);
- POSTING_READ16(GEN2_IIR);
+ intel_uncore_write16(uncore, GEN2_IIR, 0x);
+ intel_uncore_posting_read16(uncore, GEN2_IIR);
+ intel_uncore_write16(uncore, GEN2_IIR, 0x);
+ intel_uncore_posting_read16(uncore, GEN2_IIR);
}
-static void gen3_irq_init(struct drm_i915_private *dev_priv,
+static
[Intel-gfx] [PATCH 1/5] drm/i915: refactor the IRQ init/reset macros
The whole point of having macros here is for the token pasting
necessary to automatically have IMR, IIR and IER selected. We don't
really need or want all the inlining that happens as a consequence.
The good thing about the current code is that it works regardless of
the relative offsets between these registers (they change after gen4,
with the usual VLV/CHV exceptions).
One thing which we can do is to split the logic of what we do with
imr/ier/iir to functions separate from the macros that pick them.
That's what we do in this commit. This allows us to get rid of the
gen8 duplicates and also all the inlining:
add/remove: 2/0 grow/shrink: 0/21 up/down: 384/-5949 (-5565)
Function old new delta
gen3_irq_reset - 233+233
gen3_irq_init - 151+151
i8xx_irq_postinstall 459 442 -17
gen11_irq_postinstall804 744 -60
ironlake_irq_postinstall 450 353 -97
vlv_display_irq_postinstall 348 245-103
i965_irq_postinstall 378 272-106
i915_irq_postinstall 333 227-106
gen8_irq_power_well_post_enable 374 240-134
ironlake_irq_reset 397 218-179
vlv_display_irq_reset616 433-183
i965_irq_reset 374 180-194
cherryview_irq_reset 379 185-194
i915_irq_reset 407 209-198
ibx_irq_reset332 133-199
gen5_gt_irq_postinstall 533 332-201
gen8_irq_power_well_pre_disable 434 204-230
gen8_gt_irq_postinstall 469 196-273
gen8_de_irq_postinstall 1200 836-364
gen5_gt_irq_reset471 76-395
gen8_gt_irq_reset775 99-676
gen8_irq_reset 1100 333-767
gen11_irq_reset 1959 686 -1273
Total: Before=2259222, After=2253657, chg -0.25%
v2:
- Make checkpatch happy with a temporary which_ (Checkpatch).
- Reorder the arguments for the INIT macros (Ville).
- Correctly explain when the register offsets change in the commit
message (Ville).
- Use more line breaks in the macro calls to make the arguments look
a little more organized/readable.
- Update the bloat-o-meter output (minor change only).
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 136
1 file changed, 86 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8d8935d71180..60a3f4203ac3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -136,36 +136,48 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
[HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
};
-/* IIR can theoretically queue up two events. Be paranoid. */
-#define GEN8_IRQ_RESET_NDX(type, which) do { \
- I915_WRITE(GEN8_##type##_IMR(which), 0x); \
- POSTING_READ(GEN8_##type##_IMR(which)); \
- I915_WRITE(GEN8_##type##_IER(which), 0); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- POSTING_READ(GEN8_##type##_IIR(which)); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- POSTING_READ(GEN8_##type##_IIR(which)); \
-} while (0)
-
-#define GEN3_IRQ_RESET(type) do { \
- I915_WRITE(type##IMR, 0x); \
- POSTING_READ(type##IMR); \
- I915_WRITE(type##IER, 0); \
- I915_WRITE(type##IIR, 0x); \
- POSTING_READ(type##IIR); \
- I915_WRITE(type##IIR, 0x); \
- POSTING_READ(type##IIR); \
-} while (0)
-
-#define GEN2_IRQ_RESET(type) do { \
- I915_WRITE16(type##IMR, 0x); \
- POSTING_READ16(type##IMR); \
- I915_WRITE16(type##IER, 0); \
- I915_WRITE16(type##IIR, 0x); \
- POSTING_READ16(type##IIR); \
- I915_WRITE16(type##IIR, 0x); \
- POSTING_READ16(type##IIR); \
-} while (0)
+static void gen3_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+ i915_reg_t iir, i915_reg_t ier)
+{
+ I915_WRITE(imr, 0x);
+ POSTING_READ(imr);
+
+ I915_WRITE(ier, 0);
+
+ /* IIR can theoretically queue up two events. Be paranoid. */
+ I915_WRITE(iir, 0x);
+ POSTING_READ(iir);
+ I915_WRITE(iir, 0x);
+ POSTING_READ(iir);
+}
+
+static void gen2_irq_reset(struct drm_i915_private *dev_priv, i915_reg_t imr,
+ i915_reg_t iir, i915_reg_t ier)
+{
+ I915_WRITE16(imr, 0x);
+ POSTING_READ16(imr);
+
+ I915_W
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for IRQ initialization debloat and conversion to uncore (rev2)
Em qui, 2019-04-11 às 01:08 +, Patchwork escreveu: > == Series Details == > > Series: IRQ initialization debloat and conversion to uncore (rev2) > URL : https://patchwork.freedesktop.org/series/59202/ > State : success So, this is the BAT email I got yesterday. I don't see the FI.CI.IGT email anywhere: it's not showing on patchwork and it's also not showing on https://intel-gfx-ci.01.org/queue/ as something to-do. Will CI run the full IGT run in this series? Why not? I wanted to merge it. Thanks, Paulo > > == Summary == > > CI Bug Log - changes from CI_DRM_5904 -> Patchwork_12760 > > > Summary > --- > > **SUCCESS** > > No regressions found. > > External URL: > https://patchwork.freedesktop.org/api/1.0/series/59202/revisions/2/mbox/ > > Known issues > > > Here are the changes found in Patchwork_12760 that come from known issues: > > ### IGT changes ### > > Issues hit > > * igt@amdgpu/amd_cs_nop@fork-compute0: > - fi-icl-y: NOTRUN -> SKIP [fdo#109315] +17 > > * igt@gem_exec_basic@basic-bsd2: > - fi-icl-y: NOTRUN -> SKIP [fdo#109276] +7 > > * igt@gem_exec_basic@readonly-bsd1: > - fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] +57 > > * igt@gem_exec_parse@basic-rejected: > - fi-icl-y: NOTRUN -> SKIP [fdo#109289] +1 > > * igt@i915_selftest@live_contexts: > - fi-icl-y: NOTRUN -> DMESG-FAIL [fdo#108569] > > * igt@i915_selftest@live_execlists: > - fi-apl-guc: NOTRUN -> INCOMPLETE [fdo#103927] / [fdo#109720] > > * igt@i915_selftest@live_hangcheck: > - fi-bxt-dsi: PASS -> INCOMPLETE [fdo#103927] > > * igt@kms_busy@basic-flip-c: > - fi-snb-2520m: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] > > * igt@kms_chamelium@dp-crc-fast: > - fi-icl-y: NOTRUN -> SKIP [fdo#109284] +8 > > * igt@kms_force_connector_basic@force-load-detect: > - fi-icl-y: NOTRUN -> SKIP [fdo#109285] +3 > > * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: > - fi-byt-clapper: PASS -> FAIL [fdo#103191] > > * igt@kms_psr@primary_mmap_gtt: > - fi-skl-guc: NOTRUN -> SKIP [fdo#109271] +49 > - fi-icl-y: NOTRUN -> SKIP [fdo#110189] +3 > > * igt@kms_psr@primary_page_flip: > - fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +50 > > * igt@prime_vgem@basic-fence-flip: > - fi-icl-y: NOTRUN -> SKIP [fdo#109294] > > * igt@runner@aborted: > - fi-apl-guc: NOTRUN -> FAIL [fdo#108622] / [fdo#109720] > > > Possible fixes > > * igt@i915_selftest@live_contexts: > - fi-bdw-gvtdvm: DMESG-FAIL [fdo#110235 ] -> PASS > > * igt@i915_selftest@live_evict: > - fi-bsw-kefka: DMESG-WARN [fdo#107709] -> PASS > > * igt@kms_frontbuffer_tracking@basic: > - fi-byt-clapper: FAIL [fdo#103167] -> PASS > > * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: > - fi-byt-clapper: FAIL [fdo#103191] -> PASS > > > [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 > [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191 > [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 > [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 > [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 > [fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622 > [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 > [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276 > [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 > [fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284 > [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 > [fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289 > [fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294 > [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 > [fdo#109720]: https://bugs.freedesktop.org/show_bug.cgi?id=109720 > [fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189 > [fdo#110235 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 > > > Participating hosts (45 -> 38) > -- > > Additional (4): fi-icl-y fi-skl-guc fi-apl-guc fi-snb-2520m > Missing(11): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-glk-dsi > fi-byt-squawks fi-bwr-2160 fi-bsw-cyan fi-ctg-p8600 fi-blb-e6850 fi-bdw-samus > fi-kbl-r > > > Build changes > - > > * Linux: CI_DRM_5904 -> Patchwork_12760 > > CI_DRM_5904: f0ba5aa7a6ab956f01dbaf1b16720da3ca859230 @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_4942: ff8929d4d5b57b544e699fa428930f0fd66dd2dc @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_12760: 84a9eee43744c59bbfca952ea970891ee1076c77 @ > git://anongit.freedesktop.org/gfx-ci/linux > > >
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for IRQ initialization debloat and conversion to uncore (rev2)
Em seg, 2019-04-15 às 09:42 +0300, Tomi Sarvela escreveu: > On 4/12/19 11:57 PM, Paulo Zanoni wrote: > > Em qui, 2019-04-11 às 01:08 +, Patchwork escreveu: > > > == Series Details == > > > > > > Series: IRQ initialization debloat and conversion to uncore (rev2) > > > URL : https://patchwork.freedesktop.org/series/59202/ > > > State : success > > > > So, this is the BAT email I got yesterday. I don't see the FI.CI.IGT > > email anywhere: it's not showing on patchwork and it's also not showing > > on https://intel-gfx-ci.01.org/queue/ as something to-do. Will CI run > > the full IGT run in this series? Why not? I wanted to merge it. > > On Thu and Fri the CI (or rather, our lab network) had serious issues > with DNS connectivity. We're mostly clear now, one issue remains but it > shouldn't affect productivity. Thanks for letting me know. I was unsure if there was some new CI rule in place or that maybe I just did something wrong. > > Seems that the re-testing did the trick for you? Yeah, I pushed the retest button a little later I sent the email. Thanks, Paulo > > > Tomi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915: disable framebuffer compression on GeminiLake
Em qua, 2019-04-24 às 20:58 +0100, Chris Wilson escreveu:
> Quoting Jian-Hong Pan (2019-04-23 10:28:10)
> > From: Daniel Drake
> >
> > On many (all?) the Gemini Lake systems we work with, there is frequent
> > momentary graphical corruption at the top of the screen, and it seems
> > that disabling framebuffer compression can avoid this.
> >
> > The ticket was reported 6 months ago and has already affected a
> > multitude of users, without any real progress being made. So, lets
> > disable framebuffer compression on GeminiLake until a solution is found.
> >
> > Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=108085
> > Signed-off-by: Daniel Drake
> > Signed-off-by: Jian-Hong Pan
>
> Fixes: fd7d6c5c8f3e ("drm/i915: enable FBC on gen9+ too") ?
> Cc: Paulo Zanoni
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: # v4.11+
>
> glk landed 1 month before, so that seems the earliest broken point.
>
The bug is well reported, the bug author is helpful and it even has a
description of "steps to reproduce" that looks very easy (although I
didn't try it). Everything suggests this is a bug the display team
could actually solve with not-so-many hours of debugging.
In the meantime, unbreak the systems:
Reviewed-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/intel_fbc.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index 656e684e7c9a..fc018f3f53a1 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1278,6 +1278,10 @@ static int intel_sanitize_fbc_option(struct
> > drm_i915_private *dev_priv)
> > if (!HAS_FBC(dev_priv))
> > return 0;
> >
> > + /* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */
> > + if (IS_GEMINILAKE(dev_priv))
> > + return 0;
> > +
> > if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9)
> > return 1;
> >
> > --
> > 2.21.0
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop platform_mask
Em sex, 2019-03-15 às 06:56 +, Tvrtko Ursulin escreveu: > On 15/03/2019 00:52, Chris Wilson wrote: > > Quoting José Roberto de Souza (2019-03-15 00:42:35) > > > We don't have any platform that is composed by 2 or more platforms so > > > we don't need a mask, lets drop it and remove the actual limit of 32 > > > platforms. > > Platform mask was a nifty trick to compile tests like IS_SKYLAKE || > IS_BROADWELL etc into a single conditional. > So perhaps the code would benefit from a small comment that says exactly that, so the next person looking at it won't propose its removal again. José, would you volunteer for that patch? > > gcc doesn't entirely agree, this is a net loss here (i.e. code size > > increases). > > Perhaps the size re-gain of dropping the platform mask could be checked > against the size gain of making the mask 64 bit. > > However, one other benefit of the mask will also help with dead code > elimination once per SKU build work is resurfaced. For the single > selected platforms it doesn't matter, but for a subset it still does I > think. > > So I think we got two questions here - checking between size gains of > the two options, and how interesting would multi-platform builds be. > > One use case for the latter I had in mind was legacy vs execlists driver > build but that wasn't based on any formal feature requests as far as I > am aware. > > Regards, > > Tvrtko > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 01/10] drm/i915: do not pass dev_priv to low-level forcewake functions
Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> The only usage we have for it is for the regs pointer. Save a pointer to
> the set and ack registers instead of the register offsets to remove this
> requirement
Reviewed-by: Paulo Zanoni
>
> Cc: Paulo Zanoni
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 100 +---
> drivers/gpu/drm/i915/intel_uncore.h | 9 ++-
> 2 files changed, 52 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 75646a1e0051..cb78dcddc9cb 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -58,16 +58,18 @@ intel_uncore_forcewake_domain_to_str(const enum
> forcewake_domain_id id)
> return "unknown";
> }
>
> +#define fw_ack(d) readl((d)->reg_ack)
> +#define fw_set(d, val) writel((val), (d)->reg_set)
> +
> static inline void
> -fw_domain_reset(struct drm_i915_private *i915,
> - const struct intel_uncore_forcewake_domain *d)
> +fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
> {
> /*
>* We don't really know if the powerwell for the forcewake domain we are
>* trying to reset here does exist at this point (engines could be fused
>* off in ICL+), so no waiting for acks
>*/
> - __raw_i915_write32(i915, d->reg_set, i915->uncore.fw_reset);
> + fw_set(d, forcewake_domain_to_uncore(d)->fw_reset);
> }
>
> static inline void
> @@ -81,36 +83,32 @@ fw_domain_arm_timer(struct intel_uncore_forcewake_domain
> *d)
> }
>
> static inline int
> -__wait_for_ack(const struct drm_i915_private *i915,
> -const struct intel_uncore_forcewake_domain *d,
> +__wait_for_ack(const struct intel_uncore_forcewake_domain *d,
> const u32 ack,
> const u32 value)
> {
> - return wait_for_atomic((__raw_i915_read32(i915, d->reg_ack) & ack) ==
> value,
> + return wait_for_atomic((fw_ack(d) & ack) == value,
> FORCEWAKE_ACK_TIMEOUT_MS);
> }
>
> static inline int
> -wait_ack_clear(const struct drm_i915_private *i915,
> -const struct intel_uncore_forcewake_domain *d,
> +wait_ack_clear(const struct intel_uncore_forcewake_domain *d,
> const u32 ack)
> {
> - return __wait_for_ack(i915, d, ack, 0);
> + return __wait_for_ack(d, ack, 0);
> }
>
> static inline int
> -wait_ack_set(const struct drm_i915_private *i915,
> - const struct intel_uncore_forcewake_domain *d,
> +wait_ack_set(const struct intel_uncore_forcewake_domain *d,
>const u32 ack)
> {
> - return __wait_for_ack(i915, d, ack, ack);
> + return __wait_for_ack(d, ack, ack);
> }
>
> static inline void
> -fw_domain_wait_ack_clear(const struct drm_i915_private *i915,
> - const struct intel_uncore_forcewake_domain *d)
> +fw_domain_wait_ack_clear(const struct intel_uncore_forcewake_domain *d)
> {
> - if (wait_ack_clear(i915, d, FORCEWAKE_KERNEL))
> + if (wait_ack_clear(d, FORCEWAKE_KERNEL))
> DRM_ERROR("%s: timed out waiting for forcewake ack to clear.\n",
> intel_uncore_forcewake_domain_to_str(d->id));
> }
> @@ -121,8 +119,7 @@ enum ack_type {
> };
>
> static int
> -fw_domain_wait_ack_with_fallback(const struct drm_i915_private *i915,
> - const struct intel_uncore_forcewake_domain *d,
> +fw_domain_wait_ack_with_fallback(const struct intel_uncore_forcewake_domain
> *d,
>const enum ack_type type)
> {
> const u32 ack_bit = FORCEWAKE_KERNEL;
> @@ -146,72 +143,65 @@ fw_domain_wait_ack_with_fallback(const struct
> drm_i915_private *i915,
>
> pass = 1;
> do {
> - wait_ack_clear(i915, d, FORCEWAKE_KERNEL_FALLBACK);
> + wait_ack_clear(d, FORCEWAKE_KERNEL_FALLBACK);
>
> - __raw_i915_write32(i915, d->reg_set,
> -
> _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL_FALLBACK));
> + fw_set(d, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL_FALLBACK));
> /* Give gt some time to relax before the polling frenzy */
> udelay(10 * pass);
> - wait_ack_set(i915, d, FORCEWAKE_KERNEL_FALLBACK);
> + wait_ack_set(d, FORCEWAKE_KERNEL_FALLBACK);
>
> - ack_detected = (__raw_i915_read32(i915, d->reg_ack) & ack_bit)
> == value;
Re: [Intel-gfx] [RFC 02/10] drm/i915: use intel_uncore in fw get/put internal paths
Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> Get/put functions used outside of uncore.c are updated in the next
> patch for a nicer split
>
> Cc: Paulo Zanoni
> Signed-off-by: Daniele Ceraolo Spurio
I really like this one, replacing a gazillion i915->uncore.x with only
uncore->x and just very few instances where you need to go from uncore
back to i915. IMHO this patch is worth it on its own, not considering
the rest of the series.
A single comment below:
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 5 +-
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 5 +
> drivers/gpu/drm/i915/intel_uncore.c | 203 +-
> drivers/gpu/drm/i915/intel_uncore.h | 17 +-
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +-
> 6 files changed, 125 insertions(+), 109 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 6a90558de213..3bcf0e07b614 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1414,13 +1414,14 @@ static int ironlake_drpc_info(struct seq_file *m)
> static int i915_forcewake_domains(struct seq_file *m, void *data)
> {
> struct drm_i915_private *i915 = node_to_i915(m->private);
> + struct intel_uncore *uncore = &i915->uncore;
> struct intel_uncore_forcewake_domain *fw_domain;
> unsigned int tmp;
>
> seq_printf(m, "user.bypass_count = %u\n",
> -i915->uncore.user_forcewake.count);
> +uncore->user_forcewake.count);
>
> - for_each_fw_domain(fw_domain, i915, tmp)
> + for_each_fw_domain(fw_domain, uncore, tmp)
> seq_printf(m, "%s.wake_count = %u\n",
> intel_uncore_forcewake_domain_to_str(fw_domain->id),
> READ_ONCE(fw_domain->wake_count));
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 0d743907e7bc..4ace6fadfbc2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2914,7 +2914,7 @@ static int intel_runtime_suspend(struct device *kdev)
> intel_opregion_notify_adapter(dev_priv, PCI_D1);
> }
>
> - assert_forcewakes_inactive(dev_priv);
> + assert_forcewakes_inactive(&dev_priv->uncore);
>
> if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
> intel_hpd_poll_init(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index dccb6006aabf..8a4b5bbac02e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2102,6 +2102,11 @@ static inline struct drm_i915_private
> *huc_to_i915(struct intel_huc *huc)
> return container_of(huc, struct drm_i915_private, huc);
> }
>
> +static inline struct drm_i915_private *uncore_to_i915(struct intel_uncore
> *uncore)
> +{
> + return container_of(uncore, struct drm_i915_private, uncore);
> +}
> +
> /* Simple iterator over all initialised engines */
> #define for_each_engine(engine__, dev_priv__, id__) \
> for ((id__) = 0; \
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index cb78dcddc9cb..a2d9490739a0 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -205,60 +205,60 @@ fw_domain_put(const struct
> intel_uncore_forcewake_domain *d)
> }
>
> static void
> -fw_domains_get(struct drm_i915_private *i915, enum forcewake_domains
> fw_domains)
> +fw_domains_get(struct intel_uncore *uncore, enum forcewake_domains
> fw_domains)
> {
> struct intel_uncore_forcewake_domain *d;
> unsigned int tmp;
>
> - GEM_BUG_ON(fw_domains & ~i915->uncore.fw_domains);
> + GEM_BUG_ON(fw_domains & ~uncore->fw_domains);
>
> - for_each_fw_domain_masked(d, fw_domains, i915, tmp) {
> + for_each_fw_domain_masked(d, fw_domains, uncore, tmp) {
> fw_domain_wait_ack_clear(d);
> fw_domain_get(d);
> }
>
> - for_each_fw_domain_masked(d, fw_domains, i915, tmp)
> + for_each_fw_domain_masked(d, fw_domains, uncore, tmp)
> fw_domain_wait_ack_set(d);
>
> - i915->uncore.fw_domains_active |= fw_domains;
> + uncore->fw_domains_active |= fw_domains;
> }
>
> static void
> -fw_domains_get_with_fallback(struct drm_i915_private *i915,
> +fw_domains_get_with_fallback(struct intel_uncor
Re: [Intel-gfx] [RFC 03/10] drm/i915: use intel_uncore for all forcewake get/put
Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> Now that the internal code all works on intel_uncore, flip the
> external-facing interface.
Long but trivial patch. It breaks compilation of gvt but that's also
trivial to fix.
Unlike patches 1 and 2, this one doesn't add much value on its own IMHO
(i.e., without the rest of the series), but it still helps intel_uncore
move away from the God Object pattern of dev_priv. I'll add my r-b to
the version with the gvt fix when it's sent.
>
> Cc: Paulo Zanoni
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/gvt/mmio_context.c | 8 +--
> drivers/gpu/drm/i915/i915_debugfs.c | 12 ++---
> drivers/gpu/drm/i915/i915_gem.c | 20 +++
> drivers/gpu/drm/i915/i915_perf.c | 6 +--
> drivers/gpu/drm/i915/i915_reset.c | 12 ++---
> drivers/gpu/drm/i915/intel_display.c | 4 +-
> drivers/gpu/drm/i915/intel_engine_cs.c| 4 +-
> drivers/gpu/drm/i915/intel_guc.c | 8 +--
> drivers/gpu/drm/i915/intel_guc_fw.c | 4 +-
> drivers/gpu/drm/i915/intel_huc_fw.c | 4 +-
> drivers/gpu/drm/i915/intel_pm.c | 52 +--
> drivers/gpu/drm/i915/intel_ringbuffer.c | 8 +--
> drivers/gpu/drm/i915/intel_uncore.c | 50 --
> drivers/gpu/drm/i915/intel_uncore.h | 12 ++---
> drivers/gpu/drm/i915/intel_workarounds.c | 4 +-
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 4 +-
> 16 files changed, 102 insertions(+), 110 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c
> b/drivers/gpu/drm/i915/gvt/mmio_context.c
> index f64c76dd11d4..a00a807a1d55 100644
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> @@ -356,7 +356,7 @@ static void handle_tlb_pending_event(struct intel_vgpu
> *vgpu, int ring_id)
> if (ring_id == RCS0 && INTEL_GEN(dev_priv) >= 9)
> fw |= FORCEWAKE_RENDER;
>
> - intel_uncore_forcewake_get(dev_priv, fw);
> + intel_uncore_forcewake_get(&dev_priv->uncore, fw);
>
> I915_WRITE_FW(reg, 0x1);
>
> @@ -365,7 +365,7 @@ static void handle_tlb_pending_event(struct intel_vgpu
> *vgpu, int ring_id)
> else
> vgpu_vreg_t(vgpu, reg) = 0;
>
> - intel_uncore_forcewake_put(dev_priv, fw);
> + intel_uncore_forcewake_put(&dev_priv->uncore, fw);
>
> gvt_dbg_core("invalidate TLB for ring %d\n", ring_id);
> }
> @@ -552,9 +552,9 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre,
>* performace for batch mmio read/write, so we need
>* handle forcewake mannually.
>*/
> - intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(&dev_priv->uncore, FORCEWAKE_ALL);
> switch_mmio(pre, next, ring_id);
> - intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_put(&dev_priv->uncore, FORCEWAKE_ALL);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 3bcf0e07b614..0c037bbcf4c8 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1094,7 +1094,7 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
> }
>
> /* RPSTAT1 is in the GT power well */
> - intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(&dev_priv->uncore, FORCEWAKE_ALL);
>
> reqf = I915_READ(GEN6_RPNSWREQ);
> if (INTEL_GEN(dev_priv) >= 9)
> @@ -1122,7 +1122,7 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
> cagf = intel_gpu_freq(dev_priv,
> intel_get_cagf(dev_priv, rpstat));
>
> - intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_put(&dev_priv->uncore, FORCEWAKE_ALL);
>
> if (INTEL_GEN(dev_priv) >= 11) {
> pm_ier = I915_READ(GEN11_GPM_WGBOXPERF_INTR_ENABLE);
> @@ -2060,12 +2060,12 @@ static int i915_rps_boost_info(struct seq_file *m,
> void *data)
> u32 rpup, rpupei;
> u32 rpdown, rpdownei;
>
> - intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(&dev_priv->uncore, FORCEWAKE_ALL);
> rpup = I915_READ_FW(GEN6_RP_CUR_UP) & GEN6_RP_EI_MASK;
> rpupei = I915_READ_FW(GEN6_RP_CUR_UP_EI) &
Re: [Intel-gfx] [RFC 04/10] drm/i915: make more uncore function work on intel_uncore
Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> Move the init, fini, prune, suspend, resume function to work on
> intel_uncore instead of dev_priv
>
A common theme in this series is the last sentence of a commit message
missing the final period ("."). Please fix all of them :).
I think the s/dev_priv/i915/ here is a little unnecessary since it
inflates the diff even more (when will we settle with a single name?),
but okay let's go with it.
Patch still worth on its own IMHO due to all the dev_priv->uncore to
just uncore reduction.
Reviewed-by: Paulo Zanoni
> Cc: Paulo Zanoni
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/i915_drv.c | 20 +-
> drivers/gpu/drm/i915/intel_uncore.c | 290 +-
> drivers/gpu/drm/i915/intel_uncore.h | 12 +-
> .../gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
> drivers/gpu/drm/i915/selftests/mock_uncore.c | 6 +-
> drivers/gpu/drm/i915/selftests/mock_uncore.h | 2 +-
> 6 files changed, 168 insertions(+), 164 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 4ace6fadfbc2..a2e039f523c0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -993,11 +993,11 @@ static int i915_driver_init_mmio(struct
> drm_i915_private *dev_priv)
> if (ret < 0)
> goto err_bridge;
>
> - intel_uncore_init(dev_priv);
> + intel_uncore_init(&dev_priv->uncore);
>
> intel_device_info_init_mmio(dev_priv);
>
> - intel_uncore_prune(dev_priv);
> + intel_uncore_prune(&dev_priv->uncore);
>
> intel_uc_init_mmio(dev_priv);
>
> @@ -1010,7 +1010,7 @@ static int i915_driver_init_mmio(struct
> drm_i915_private *dev_priv)
> return 0;
>
> err_uncore:
> - intel_uncore_fini(dev_priv);
> + intel_uncore_fini(&dev_priv->uncore);
> i915_mmio_cleanup(dev_priv);
> err_bridge:
> pci_dev_put(dev_priv->bridge_dev);
> @@ -1024,7 +1024,7 @@ static int i915_driver_init_mmio(struct
> drm_i915_private *dev_priv)
> */
> static void i915_driver_cleanup_mmio(struct drm_i915_private *dev_priv)
> {
> - intel_uncore_fini(dev_priv);
> + intel_uncore_fini(&dev_priv->uncore);
> i915_mmio_cleanup(dev_priv);
> pci_dev_put(dev_priv->bridge_dev);
> }
> @@ -2086,7 +2086,7 @@ static int i915_drm_suspend_late(struct drm_device
> *dev, bool hibernation)
>
> i915_gem_suspend_late(dev_priv);
>
> - intel_uncore_suspend(dev_priv);
> + intel_uncore_suspend(&dev_priv->uncore);
>
> intel_power_domains_suspend(dev_priv,
> get_suspend_mode(dev_priv, hibernation));
> @@ -2282,7 +2282,9 @@ static int i915_drm_resume_early(struct drm_device *dev)
> DRM_ERROR("Resume prepare failed: %d, continuing anyway\n",
> ret);
>
> - intel_uncore_resume_early(dev_priv);
> + intel_uncore_resume_early(&dev_priv->uncore);
> +
> + i915_check_and_clear_faults(dev_priv);
>
> if (INTEL_GEN(dev_priv) >= 11 || IS_GEN9_LP(dev_priv)) {
> gen9_sanitize_dc_state(dev_priv);
> @@ -2852,7 +2854,7 @@ static int intel_runtime_suspend(struct device *kdev)
>
> intel_runtime_pm_disable_interrupts(dev_priv);
>
> - intel_uncore_suspend(dev_priv);
> + intel_uncore_suspend(&dev_priv->uncore);
>
> ret = 0;
> if (INTEL_GEN(dev_priv) >= 11) {
> @@ -2869,7 +2871,7 @@ static int intel_runtime_suspend(struct device *kdev)
>
> if (ret) {
> DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
> - intel_uncore_runtime_resume(dev_priv);
> + intel_uncore_runtime_resume(&dev_priv->uncore);
>
> intel_runtime_pm_enable_interrupts(dev_priv);
>
> @@ -2966,7 +2968,7 @@ static int intel_runtime_resume(struct device *kdev)
> ret = vlv_resume_prepare(dev_priv, true);
> }
>
> - intel_uncore_runtime_resume(dev_priv);
> + intel_uncore_runtime_resume(&dev_priv->uncore);
>
> intel_runtime_pm_enable_interrupts(dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 75279c627388..dd81c2655e2d 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -523,62 +523,58 @@ check_for_unclaimed_mmio(struct drm_i915_private
> *dev_priv)
> return ret;
> }
>
> -static void __intel_uncore_earl
Re: [Intel-gfx] [RFC 05/10] drm/i915: make find_fw_domain work on intel_uncore
Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> Remove unneeded usage of dev_priv from 1 extra function.
>
Reviewed-by: Paulo Zanoni
> Cc: Paulo Zanoni
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index dd81c2655e2d..afbbefc32227 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -833,13 +833,13 @@ static int fw_range_cmp(u32 offset, const struct
> intel_forcewake_range *entry)
> })
>
> static enum forcewake_domains
> -find_fw_domain(struct drm_i915_private *dev_priv, u32 offset)
> +find_fw_domain(struct intel_uncore *uncore, u32 offset)
> {
> const struct intel_forcewake_range *entry;
>
> entry = BSEARCH(offset,
> - dev_priv->uncore.fw_domains_table,
> - dev_priv->uncore.fw_domains_table_entries,
> + uncore->fw_domains_table,
> + uncore->fw_domains_table_entries,
> fw_range_cmp);
>
> if (!entry)
> @@ -851,11 +851,11 @@ find_fw_domain(struct drm_i915_private *dev_priv, u32
> offset)
>* translate it here to the list of available domains.
>*/
> if (entry->domains == FORCEWAKE_ALL)
> - return dev_priv->uncore.fw_domains;
> + return uncore->fw_domains;
>
> - WARN(entry->domains & ~dev_priv->uncore.fw_domains,
> + WARN(entry->domains & ~uncore->fw_domains,
>"Uninitialized forcewake domain(s) 0x%x accessed at 0x%x\n",
> - entry->domains & ~dev_priv->uncore.fw_domains, offset);
> + entry->domains & ~uncore->fw_domains, offset);
>
> return entry->domains;
> }
> @@ -883,7 +883,7 @@ static const struct intel_forcewake_range
> __vlv_fw_ranges[] = {
> ({ \
> enum forcewake_domains __fwd = 0; \
> if (NEEDS_FORCE_WAKE((offset))) \
> - __fwd = find_fw_domain(dev_priv, offset); \
> + __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> __fwd; \
> })
>
> @@ -891,7 +891,7 @@ static const struct intel_forcewake_range
> __vlv_fw_ranges[] = {
> ({ \
> enum forcewake_domains __fwd = 0; \
> if (GEN11_NEEDS_FORCE_WAKE((offset))) \
> - __fwd = find_fw_domain(dev_priv, offset); \
> + __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> __fwd; \
> })
>
> @@ -977,7 +977,7 @@ static const struct intel_forcewake_range
> __chv_fw_ranges[] = {
> ({ \
> enum forcewake_domains __fwd = 0; \
> if (NEEDS_FORCE_WAKE((offset)) && !is_gen8_shadowed(offset)) \
> - __fwd = find_fw_domain(dev_priv, offset); \
> + __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> __fwd; \
> })
>
> @@ -985,7 +985,7 @@ static const struct intel_forcewake_range
> __chv_fw_ranges[] = {
> ({ \
> enum forcewake_domains __fwd = 0; \
> if (GEN11_NEEDS_FORCE_WAKE((offset)) && !is_gen11_shadowed(offset)) \
> - __fwd = find_fw_domain(dev_priv, offset); \
> + __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> __fwd; \
> })
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 06/10] drm/i915: reduce the dev_priv->uncore dance in uncore.c
Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> Use a local variable where it makes sense.
Also worth it on its own IMHO.
Reviewed-by: Paulo Zanoni
>
> Cc: Paulo Zanoni
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 79 -
> 1 file changed, 43 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index afbbefc32227..32c75337b96d 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -311,6 +311,7 @@ static inline u32 fifo_free_entries(struct
> drm_i915_private *dev_priv)
>
> static void __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
> {
> + struct intel_uncore *uncore = &dev_priv->uncore;
> u32 n;
>
> /* On VLV, FIFO will be shared by both SW and HW.
> @@ -318,7 +319,7 @@ static void __gen6_gt_wait_for_fifo(struct
> drm_i915_private *dev_priv)
> if (IS_VALLEYVIEW(dev_priv))
> n = fifo_free_entries(dev_priv);
> else
> - n = dev_priv->uncore.fifo_count;
> + n = uncore->fifo_count;
>
> if (n <= GT_FIFO_NUM_RESERVED_ENTRIES) {
> if (wait_for_atomic((n = fifo_free_entries(dev_priv)) >
> @@ -329,7 +330,7 @@ static void __gen6_gt_wait_for_fifo(struct
> drm_i915_private *dev_priv)
> }
> }
>
> - dev_priv->uncore.fifo_count = n - 1;
> + uncore->fifo_count = n - 1;
> }
>
> static enum hrtimer_restart
> @@ -793,7 +794,7 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
> #define GEN11_NEEDS_FORCE_WAKE(reg) \
> ((reg) < 0x4 || ((reg) >= 0x1c && (reg) < 0x1dc000))
>
> -#define __gen6_reg_read_fw_domains(offset) \
> +#define __gen6_reg_read_fw_domains(uncore, offset) \
> ({ \
> enum forcewake_domains __fwd; \
> if (NEEDS_FORCE_WAKE(offset)) \
> @@ -879,19 +880,19 @@ static const struct intel_forcewake_range
> __vlv_fw_ranges[] = {
> GEN_FW_RANGE(0x3, 0x3, FORCEWAKE_MEDIA),
> };
>
> -#define __fwtable_reg_read_fw_domains(offset) \
> +#define __fwtable_reg_read_fw_domains(uncore, offset) \
> ({ \
> enum forcewake_domains __fwd = 0; \
> if (NEEDS_FORCE_WAKE((offset))) \
> - __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> + __fwd = find_fw_domain(uncore, offset); \
> __fwd; \
> })
>
> -#define __gen11_fwtable_reg_read_fw_domains(offset) \
> +#define __gen11_fwtable_reg_read_fw_domains(uncore, offset) \
> ({ \
> enum forcewake_domains __fwd = 0; \
> if (GEN11_NEEDS_FORCE_WAKE((offset))) \
> - __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> + __fwd = find_fw_domain(uncore, offset); \
> __fwd; \
> })
>
> @@ -943,7 +944,7 @@ static bool is_gen##x##_shadowed(u32 offset) \
> __is_genX_shadowed(8)
> __is_genX_shadowed(11)
>
> -#define __gen8_reg_write_fw_domains(offset) \
> +#define __gen8_reg_write_fw_domains(uncore, offset) \
> ({ \
> enum forcewake_domains __fwd; \
> if (NEEDS_FORCE_WAKE(offset) && !is_gen8_shadowed(offset)) \
> @@ -973,19 +974,19 @@ static const struct intel_forcewake_range
> __chv_fw_ranges[] = {
> GEN_FW_RANGE(0x3, 0x37fff, FORCEWAKE_MEDIA),
> };
>
> -#define __fwtable_reg_write_fw_domains(offset) \
> +#define __fwtable_reg_write_fw_domains(uncore, offset) \
> ({ \
> enum forcewake_domains __fwd = 0; \
> if (NEEDS_FORCE_WAKE((offset)) && !is_gen8_shadowed(offset)) \
> - __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> + __fwd = find_fw_domain(uncore, offset); \
> __fwd; \
> })
>
> -#define __gen11_fwtable_reg_write_fw_domains(offset) \
> +#define __gen11_fwtable_reg_write_fw_domains(uncore, offset) \
> ({ \
> enum forcewake_domains __fwd = 0; \
> if (GEN11_NEEDS_FORCE_WAKE((offset)) && !is_gen11_shadowed(offset)) \
> - __fwd = find_fw_domain(&dev_priv->uncore, offset); \
> + __fwd = find_fw_domain(uncore, offset); \
> __fwd; \
> })
>
> @@ -1135,16 +1136,17 @@ __gen2_read(64)
> #undef GEN2_READ_HEADER
>
> #define GEN6_READ_HEADER(x) \
> + struct intel_uncore *uncore = &dev_priv->uncore; \
> u32 offset = i915_mmio_reg_offset(reg); \
> unsigned long irqflags; \
> u##x val = 0; \
> assert_rpm_wakelock_held(dev_priv); \
> - spin_lock_irqsave(&dev_priv->uncore.lock, irqflags
Re: [Intel-gfx] [RFC 08/10] drm/i915: make raw access function work on uncore
Em qua, 2019-03-13 às 16:13 -0700, Daniele Ceraolo Spurio escreveu:
> This allows us to ditch i915 in some more places.
>
> RFC: should we just make them work directly on the regs pointer instead?
Both options look better than passing God Object dev_priv, so I'm fine
with either.
To give a parallel with other parts of the driver, in display code we
tend to pass struct intel_crtc as much as possible and only pass enum
pipe when it doesn't make sense anymore to pass a CRTC. So uncore makes
sense here.
More below:
>
> Cc: Paulo Zanoni
> Signed-off-by: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/i915_drv.h | 14 ++---
> drivers/gpu/drm/i915/i915_vgpu.c| 8 ++-
> drivers/gpu/drm/i915/intel_uncore.c | 90 +++--
> 3 files changed, 58 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 293bf68fd8ba..a1b8059cd7f8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3485,17 +3485,17 @@ static inline u64 intel_rc6_residency_us(struct
> drm_i915_private *dev_priv,
> #define POSTING_READ16(reg) (void)I915_READ16_NOTRACE(reg)
>
> #define __raw_read(x, s) \
> -static inline uint##x##_t __raw_i915_read##x(const struct drm_i915_private
> *dev_priv, \
> +static inline uint##x##_t __raw_i915_read##x(const struct intel_uncore
> *uncore, \
>i915_reg_t reg) \
> { \
> - return read##s(dev_priv->uncore.regs + i915_mmio_reg_offset(reg)); \
> + return read##s(uncore->regs + i915_mmio_reg_offset(reg)); \
> }
>
> #define __raw_write(x, s) \
> -static inline void __raw_i915_write##x(const struct drm_i915_private
> *dev_priv, \
> +static inline void __raw_i915_write##x(const struct intel_uncore *uncore, \
> i915_reg_t reg, uint##x##_t val) \
> { \
> - write##s(val, dev_priv->uncore.regs + i915_mmio_reg_offset(reg)); \
> + write##s(val, uncore->regs + i915_mmio_reg_offset(reg)); \
> }
> __raw_read(8, b)
> __raw_read(16, w)
> @@ -3536,9 +3536,9 @@ __raw_write(64, q)
> * therefore generally be serialised, by either the dev_priv->uncore.lock or
> * a more localised lock guarding all access to that bank of registers.
> */
> -#define I915_READ_FW(reg__) __raw_i915_read32(dev_priv, (reg__))
> -#define I915_WRITE_FW(reg__, val__) __raw_i915_write32(dev_priv, (reg__),
> (val__))
> -#define I915_WRITE64_FW(reg__, val__) __raw_i915_write64(dev_priv, (reg__),
> (val__))
> +#define I915_READ_FW(reg__) __raw_i915_read32(&dev_priv->uncore, (reg__))
> +#define I915_WRITE_FW(reg__, val__) __raw_i915_write32(&dev_priv->uncore,
> (reg__), (val__))
> +#define I915_WRITE64_FW(reg__, val__) __raw_i915_write64(&dev_priv->uncore,
> (reg__), (val__))
Looking forward to the day dev_priv won't be implicit in register
read/write macros :).
> #define POSTING_READ_FW(reg__) (void)I915_READ_FW(reg__)
>
> /* "Broadcast RGB" property */
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 869cf4a3b6de..51e5e2630eec 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -65,17 +65,19 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
You could have gone for a local intel_uncore variable here too.
With or without that:
Reviewed-by: Paulo Zanoni
>
> BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
>
> - magic = __raw_i915_read64(dev_priv, vgtif_reg(magic));
> + magic = __raw_i915_read64(&dev_priv->uncore, vgtif_reg(magic));
> if (magic != VGT_MAGIC)
> return;
>
> - version_major = __raw_i915_read16(dev_priv, vgtif_reg(version_major));
> + version_major = __raw_i915_read16(&dev_priv->uncore,
> + vgtif_reg(version_major));
> if (version_major < VGT_VERSION_MAJOR) {
> DRM_INFO("VGT interface version mismatch!\n");
> return;
> }
>
> - dev_priv->vgpu.caps = __raw_i915_read32(dev_priv, vgtif_reg(vgt_caps));
> + dev_priv->vgpu.caps = __raw_i915_read32(&dev_priv->uncore,
> + vgtif_reg(vgt_caps));
>
> dev_priv->vgpu.active = true;
> DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index ce076d046b65..4c20b2fc33fe 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>
Re: [Intel-gfx] [PATCH v2 01/10] drm/i915: always use masks on FW regs
Em ter, 2019-03-19 às 11:35 -0700, Daniele Ceraolo Spurio escreveu:
> Upper bits are reserved on gen6, so no issue if we write them. Note that
> we're already doing this in the non-MT case of IVB, which uses the same
> register.
If, and only if, you can guarantee that writing ones to the reserved
bits in gen6 is not an issue, then everything else looks correct:
Reviewed-by: Paulo Zanoni
I also couldn't find information about WaRsClearFWBitsAtReset. Don't we
need to update its tags to include the most recent platforms and
ivb/hsw/vlv?
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 44 +++--
> drivers/gpu/drm/i915/intel_uncore.h | 4 ---
> 2 files changed, 16 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 7129eebc333b..b4cea3cf3915 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -59,18 +59,19 @@ intel_uncore_forcewake_domain_to_str(const enum
> forcewake_domain_id id)
> }
>
> #define fw_ack(d) readl((d)->reg_ack)
> -#define fw_set(d, val) writel((val), (d)->reg_set)
> +#define fw_set(d, val) writel(_MASKED_BIT_ENABLE((val)), (d)->reg_set)
> +#define fw_clear(d, val) writel(_MASKED_BIT_DISABLE((val)), (d)->reg_set)
>
> static inline void
> -fw_domain_reset(const struct intel_uncore *uncore,
> - const struct intel_uncore_forcewake_domain *d)
> +fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
> {
> /*
>* We don't really know if the powerwell for the forcewake domain we are
>* trying to reset here does exist at this point (engines could be fused
>* off in ICL+), so no waiting for acks
>*/
> - fw_set(d, uncore->fw_reset);
> + /* WaRsClearFWBitsAtReset:bdw,skl */
> + fw_clear(d, 0x);
> }
>
> static inline void
> @@ -146,14 +147,14 @@ fw_domain_wait_ack_with_fallback(const struct
> intel_uncore_forcewake_domain *d,
> do {
> wait_ack_clear(d, FORCEWAKE_KERNEL_FALLBACK);
>
> - fw_set(d, _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL_FALLBACK));
> + fw_set(d, FORCEWAKE_KERNEL_FALLBACK);
> /* Give gt some time to relax before the polling frenzy */
> udelay(10 * pass);
> wait_ack_set(d, FORCEWAKE_KERNEL_FALLBACK);
>
> ack_detected = (fw_ack(d) & ack_bit) == value;
>
> - fw_set(d, _MASKED_BIT_DISABLE(FORCEWAKE_KERNEL_FALLBACK));
> + fw_clear(d, FORCEWAKE_KERNEL_FALLBACK);
> } while (!ack_detected && pass++ < 10);
>
> DRM_DEBUG_DRIVER("%s had to use fallback to %s ack, 0x%x (passes %u)\n",
> @@ -176,10 +177,9 @@ fw_domain_wait_ack_clear_fallback(const struct
> intel_uncore_forcewake_domain *d)
> }
>
> static inline void
> -fw_domain_get(const struct intel_uncore *uncore,
> - const struct intel_uncore_forcewake_domain *d)
> +fw_domain_get(const struct intel_uncore_forcewake_domain *d)
> {
> - fw_set(d, uncore->fw_set);
> + fw_set(d, FORCEWAKE_KERNEL);
> }
>
> static inline void
> @@ -201,10 +201,9 @@ fw_domain_wait_ack_set_fallback(const struct
> intel_uncore_forcewake_domain *d)
> }
>
> static inline void
> -fw_domain_put(const struct intel_uncore *uncore,
> - const struct intel_uncore_forcewake_domain *d)
> +fw_domain_put(const struct intel_uncore_forcewake_domain *d)
> {
> - fw_set(d, uncore->fw_clear);
> + fw_clear(d, FORCEWAKE_KERNEL);
> }
>
> static void
> @@ -218,7 +217,7 @@ fw_domains_get(struct drm_i915_private *i915, enum
> forcewake_domains fw_domains)
>
> for_each_fw_domain_masked(d, fw_domains, i915, tmp) {
> fw_domain_wait_ack_clear(d);
> - fw_domain_get(uncore, d);
> + fw_domain_get(d);
> }
>
> for_each_fw_domain_masked(d, fw_domains, i915, tmp)
> @@ -239,7 +238,7 @@ fw_domains_get_with_fallback(struct drm_i915_private
> *i915,
>
> for_each_fw_domain_masked(d, fw_domains, i915, tmp) {
> fw_domain_wait_ack_clear_fallback(d);
> - fw_domain_get(uncore, d);
> + fw_domain_get(d);
> }
>
> for_each_fw_domain_masked(d, fw_domains, i915, tmp)
> @@ -258,7 +257,7 @@ fw_domains_put(struct drm_i915_private *i915, enum
> forcewake_domains fw_domains)
> GEM_BUG_ON(fw_domains & ~uncore->fw_domains);
>
> for_each_fw_domain_masked(d, fw_domains,
Re: [Intel-gfx] [PATCH v2 03/10] drm/i915: use intel_uncore for all forcewake get/put
Em ter, 2019-03-19 às 11:35 -0700, Daniele Ceraolo Spurio escreveu:
> Now that the internal code all works on intel_uncore, flip the
> external-facing interface.
>
> v2: fix GVT.
Could maybe use some local intel_uncore variables in functions, but
let's go with the current color:
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/gvt/mmio_context.c | 8 +--
> drivers/gpu/drm/i915/gvt/scheduler.c | 4 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 12 ++---
> drivers/gpu/drm/i915/i915_gem.c | 20 +++
> drivers/gpu/drm/i915/i915_perf.c | 6 +--
> drivers/gpu/drm/i915/i915_reset.c | 12 ++---
> drivers/gpu/drm/i915/intel_display.c | 4 +-
> drivers/gpu/drm/i915/intel_engine_cs.c| 4 +-
> drivers/gpu/drm/i915/intel_guc.c | 8 +--
> drivers/gpu/drm/i915/intel_guc_fw.c | 4 +-
> drivers/gpu/drm/i915/intel_huc_fw.c | 4 +-
> drivers/gpu/drm/i915/intel_pm.c | 52 +--
> drivers/gpu/drm/i915/intel_ringbuffer.c | 8 +--
> drivers/gpu/drm/i915/intel_uncore.c | 52 ---
> drivers/gpu/drm/i915/intel_uncore.h | 12 ++---
> drivers/gpu/drm/i915/intel_workarounds.c | 4 +-
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 4 +-
> 17 files changed, 105 insertions(+), 113 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c
> b/drivers/gpu/drm/i915/gvt/mmio_context.c
> index f64c76dd11d4..a00a807a1d55 100644
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> @@ -356,7 +356,7 @@ static void handle_tlb_pending_event(struct intel_vgpu
> *vgpu, int ring_id)
> if (ring_id == RCS0 && INTEL_GEN(dev_priv) >= 9)
> fw |= FORCEWAKE_RENDER;
>
> - intel_uncore_forcewake_get(dev_priv, fw);
> + intel_uncore_forcewake_get(&dev_priv->uncore, fw);
>
> I915_WRITE_FW(reg, 0x1);
>
> @@ -365,7 +365,7 @@ static void handle_tlb_pending_event(struct intel_vgpu
> *vgpu, int ring_id)
> else
> vgpu_vreg_t(vgpu, reg) = 0;
>
> - intel_uncore_forcewake_put(dev_priv, fw);
> + intel_uncore_forcewake_put(&dev_priv->uncore, fw);
>
> gvt_dbg_core("invalidate TLB for ring %d\n", ring_id);
> }
> @@ -552,9 +552,9 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre,
>* performace for batch mmio read/write, so we need
>* handle forcewake mannually.
>*/
> - intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(&dev_priv->uncore, FORCEWAKE_ALL);
> switch_mmio(pre, next, ring_id);
> - intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_put(&dev_priv->uncore, FORCEWAKE_ALL);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 7550e09939ae..3faf2438b9bc 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -988,7 +988,7 @@ static int workload_thread(void *priv)
> workload->ring_id, workload);
>
> if (need_force_wake)
> - intel_uncore_forcewake_get(gvt->dev_priv,
> + intel_uncore_forcewake_get(&gvt->dev_priv->uncore,
> FORCEWAKE_ALL);
>
> ret = dispatch_workload(workload);
> @@ -1010,7 +1010,7 @@ static int workload_thread(void *priv)
> complete_current_workload(gvt, ring_id);
>
> if (need_force_wake)
> - intel_uncore_forcewake_put(gvt->dev_priv,
> + intel_uncore_forcewake_put(&gvt->dev_priv->uncore,
> FORCEWAKE_ALL);
>
> intel_runtime_pm_put_unchecked(gvt->dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a52b7cf1525d..0dd8b3fa7fb9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1094,7 +1094,7 @@ static int i915_frequency_info(struct seq_file *m, void
> *unused)
> }
>
> /* RPSTAT1 is in the GT power well */
> - intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + intel_uncore_forcewake_get(&dev_priv->uncore, FORCEWAKE_ALL);
>
> reqf = I915_READ(GEN6_RPNSWREQ);
> if (INTEL_GEN(dev_priv) >
Re: [Intel-gfx] [PATCH v2 07/10] drm/i915: move regs pointer inside the uncore structure
Em ter, 2019-03-19 às 11:35 -0700, Daniele Ceraolo Spurio escreveu:
> This will allow futher simplifications in the uncore handling.
>
> v2: move register access setup under uncore (Chris)
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.c | 49 +++---
> drivers/gpu/drm/i915/i915_drv.h | 6 ++--
> drivers/gpu/drm/i915/i915_irq.c | 22 ++--
> drivers/gpu/drm/i915/intel_lrc.c| 6 ++--
> drivers/gpu/drm/i915/intel_uncore.c | 54 ++---
> drivers/gpu/drm/i915/intel_uncore.h | 4 ++-
> 6 files changed, 74 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5561488ecfcd..ca41a3da1918 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -930,46 +930,6 @@ static void i915_driver_cleanup_early(struct
> drm_i915_private *dev_priv)
> i915_engines_cleanup(dev_priv);
> }
>
> -static int i915_mmio_setup(struct drm_i915_private *dev_priv)
> -{
> - struct pci_dev *pdev = dev_priv->drm.pdev;
> - int mmio_bar;
> - int mmio_size;
> -
> - mmio_bar = IS_GEN(dev_priv, 2) ? 1 : 0;
> - /*
> - * Before gen4, the registers and the GTT are behind different BARs.
> - * However, from gen4 onwards, the registers and the GTT are shared
> - * in the same BAR, so we want to restrict this ioremap from
> - * clobbering the GTT which we want ioremap_wc instead. Fortunately,
> - * the register BAR remains the same size for all the earlier
> - * generations up to Ironlake.
> - */
> - if (INTEL_GEN(dev_priv) < 5)
> - mmio_size = 512 * 1024;
> - else
> - mmio_size = 2 * 1024 * 1024;
> - dev_priv->regs = pci_iomap(pdev, mmio_bar, mmio_size);
> - if (dev_priv->regs == NULL) {
> - DRM_ERROR("failed to map registers\n");
> -
> - return -EIO;
> - }
> -
> - /* Try to make sure MCHBAR is enabled before poking at it */
> - intel_setup_mchbar(dev_priv);
> -
> - return 0;
> -}
> -
> -static void i915_mmio_cleanup(struct drm_i915_private *dev_priv)
> -{
> - struct pci_dev *pdev = dev_priv->drm.pdev;
> -
> - intel_teardown_mchbar(dev_priv);
> - pci_iounmap(pdev, dev_priv->regs);
> -}
> -
> /**
> * i915_driver_init_mmio - setup device MMIO
> * @dev_priv: device private
> @@ -989,11 +949,12 @@ static int i915_driver_init_mmio(struct
> drm_i915_private *dev_priv)
> if (i915_get_bridge_dev(dev_priv))
> return -EIO;
>
> - ret = i915_mmio_setup(dev_priv);
> + ret = intel_uncore_init(&dev_priv->uncore);
> if (ret < 0)
> goto err_bridge;
>
> - intel_uncore_init(&dev_priv->uncore);
> + /* Try to make sure MCHBAR is enabled before poking at it */
> + intel_setup_mchbar(dev_priv);
>
> intel_device_info_init_mmio(dev_priv);
>
> @@ -1010,8 +971,8 @@ static int i915_driver_init_mmio(struct drm_i915_private
> *dev_priv)
> return 0;
>
> err_uncore:
> + intel_teardown_mchbar(dev_priv);
> intel_uncore_fini(&dev_priv->uncore);
> - i915_mmio_cleanup(dev_priv);
> err_bridge:
> pci_dev_put(dev_priv->bridge_dev);
>
> @@ -1024,8 +985,8 @@ static int i915_driver_init_mmio(struct drm_i915_private
> *dev_priv)
> */
> static void i915_driver_cleanup_mmio(struct drm_i915_private *dev_priv)
> {
> + intel_teardown_mchbar(dev_priv);
> intel_uncore_fini(&dev_priv->uncore);
> - i915_mmio_cleanup(dev_priv);
> pci_dev_put(dev_priv->bridge_dev);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 64f0e13d6912..58a77b01fe71 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1505,8 +1505,6 @@ struct drm_i915_private {
>*/
> resource_size_t stolen_usable_size; /* Total size minus reserved
> ranges */
>
> - void __iomem *regs;
> -
> struct intel_uncore uncore;
>
> struct i915_virtual_gpu vgpu;
> @@ -3488,14 +3486,14 @@ static inline u64 intel_rc6_residency_us(struct
> drm_i915_private *dev_priv,
> static inline uint##x##_t __raw_i915_read##x(const struct drm_i915_private
> *dev_priv, \
>i915_reg_t reg) \
> { \
> - return read##s(dev_priv->regs + i915_mmio_reg_offset(reg)); \
> + return read##s(dev_priv
Re: [Intel-gfx] [PATCH v2 09/10] drm/i915: add uncore flags
Em ter, 2019-03-19 às 11:35 -0700, Daniele Ceraolo Spurio escreveu:
> Save some uncore properties to avoid having to jump back to
> dev_priv every time
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.c | 4 +-
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_hangcheck.c| 2 +-
> drivers/gpu/drm/i915/intel_uncore.c | 82 ++-
> drivers/gpu/drm/i915/intel_uncore.h | 10 ++-
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 15 ++--
> 6 files changed, 65 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ca41a3da1918..c609bcac8577 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2849,7 +2849,7 @@ static int intel_runtime_suspend(struct device *kdev)
> enable_rpm_wakeref_asserts(dev_priv);
> intel_runtime_pm_cleanup(dev_priv);
>
> - if (intel_uncore_arm_unclaimed_mmio_detection(dev_priv))
> + if (intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore))
> DRM_ERROR("Unclaimed access detected prior to suspending\n");
>
> dev_priv->runtime_pm.suspended = true;
> @@ -2903,7 +2903,7 @@ static int intel_runtime_resume(struct device *kdev)
>
> intel_opregion_notify_adapter(dev_priv, PCI_D0);
> dev_priv->runtime_pm.suspended = false;
> - if (intel_uncore_unclaimed_mmio(dev_priv))
> + if (intel_uncore_unclaimed_mmio(&dev_priv->uncore))
> DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
>
> if (INTEL_GEN(dev_priv) >= 11) {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d4fcad136120..cfe379e938e6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13517,7 +13517,7 @@ static void intel_atomic_commit_tail(struct
> drm_atomic_state *state)
>* so enable debugging for the next modeset - and hope we catch
>* the culprit.
>*/
> - intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
> + intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore);
> intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET,
> wakeref);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index 57ed49dc19c4..125662c64934 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -270,7 +270,7 @@ static void i915_hangcheck_elapsed(struct work_struct
> *work)
>* periodically arm the mmio checker to see if we are triggering
>* any invalid access.
>*/
> - intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
> + intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore);
>
> for_each_engine(engine, dev_priv, id) {
> struct hangcheck hc;
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 1816eeae3ba9..26b28afb4500 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -509,18 +509,17 @@ gen6_check_for_fifo_debug(struct intel_uncore *uncore)
> }
>
> static bool
> -check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> +check_for_unclaimed_mmio(struct intel_uncore *uncore)
> {
> - struct intel_uncore *uncore = &dev_priv->uncore;
> bool ret = false;
>
> - if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> + if (uncore->flags & UNCORE_HAS_FPGA_DBG_UNCLAIMED)
> ret |= fpga_check_for_unclaimed_mmio(uncore);
>
> - if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + if (uncore->flags & UNCORE_HAS_DBG_UNCLAIMED)
> ret |= vlv_check_for_unclaimed_mmio(uncore);
>
> - if (IS_GEN_RANGE(dev_priv, 6, 7))
> + if (uncore->flags & UNCORE_HAS_FIFO)
> ret |= gen6_check_for_fifo_debug(uncore);
>
> return ret;
> @@ -529,14 +528,12 @@ check_for_unclaimed_mmio(struct drm_i915_private
> *dev_priv)
> static void __intel_uncore_early_sanitize(struct intel_uncore *uncore,
> unsigned int restore_forcewake)
> {
> - struct drm_i915_private *i915 = uncore_to_i915(uncore);
> -
> /* clear out unclaimed reg detection bit */
> - if (check_for_unclaimed_mmio(i915))
> + if (check_for_unclaimed_mmio(uncore))
>
Re: [Intel-gfx] [PATCH 1/9] drm/i915: rename raw reg access functions
Em seg, 2019-03-25 às 14:49 -0700, Daniele Ceraolo Spurio escreveu:
> They now work on uncore, so use raw_uncore_ prefix. Also move them to
> uncore.h
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.h | 32 ++-
> drivers/gpu/drm/i915/i915_vgpu.c| 6 ++--
> drivers/gpu/drm/i915/intel_uncore.c | 48 ++---
> drivers/gpu/drm/i915/intel_uncore.h | 27
> 4 files changed, 57 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4e30f7b19b51..558d40f07ffe 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3507,32 +3507,6 @@ static inline u64 intel_rc6_residency_us(struct
> drm_i915_private *dev_priv,
> #define POSTING_READ(reg)(void)I915_READ_NOTRACE(reg)
> #define POSTING_READ16(reg) (void)I915_READ16_NOTRACE(reg)
>
> -#define __raw_read(x, s) \
> -static inline uint##x##_t __raw_i915_read##x(const struct intel_uncore
> *uncore, \
> - i915_reg_t reg) \
> -{ \
> - return read##s(uncore->regs + i915_mmio_reg_offset(reg)); \
> -}
> -
> -#define __raw_write(x, s) \
> -static inline void __raw_i915_write##x(const struct intel_uncore *uncore, \
> -i915_reg_t reg, uint##x##_t val) \
> -{ \
> - write##s(val, uncore->regs + i915_mmio_reg_offset(reg)); \
> -}
> -__raw_read(8, b)
> -__raw_read(16, w)
> -__raw_read(32, l)
> -__raw_read(64, q)
> -
> -__raw_write(8, b)
> -__raw_write(16, w)
> -__raw_write(32, l)
> -__raw_write(64, q)
> -
> -#undef __raw_read
> -#undef __raw_write
> -
> /* These are untraced mmio-accessors that are only valid to be used inside
> * critical sections, such as inside IRQ handlers, where forcewake is
> explicitly
> * controlled.
> @@ -3559,9 +3533,9 @@ __raw_write(64, q)
> * therefore generally be serialised, by either the dev_priv->uncore.lock or
> * a more localised lock guarding all access to that bank of registers.
> */
> -#define I915_READ_FW(reg__) __raw_i915_read32(&dev_priv->uncore, (reg__))
> -#define I915_WRITE_FW(reg__, val__) __raw_i915_write32(&dev_priv->uncore,
> (reg__), (val__))
> -#define I915_WRITE64_FW(reg__, val__) __raw_i915_write64(&dev_priv->uncore,
> (reg__), (val__))
> +#define I915_READ_FW(reg__) __raw_uncore_read32(&dev_priv->uncore, (reg__))
> +#define I915_WRITE_FW(reg__, val__) __raw_uncore_write32(&dev_priv->uncore,
> (reg__), (val__))
> +#define I915_WRITE64_FW(reg__, val__)
> __raw_uncore_write64(&dev_priv->uncore, (reg__), (val__))
> #define POSTING_READ_FW(reg__) (void)I915_READ_FW(reg__)
>
> /* "Broadcast RGB" property */
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 3d0b493e4200..94d3992b599d 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -66,17 +66,17 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
>
> BUILD_BUG_ON(sizeof(struct vgt_if) != VGT_PVINFO_SIZE);
>
> - magic = __raw_i915_read64(uncore, vgtif_reg(magic));
> + magic = __raw_uncore_read64(uncore, vgtif_reg(magic));
> if (magic != VGT_MAGIC)
> return;
>
> - version_major = __raw_i915_read16(uncore, vgtif_reg(version_major));
> + version_major = __raw_uncore_read16(uncore, vgtif_reg(version_major));
> if (version_major < VGT_VERSION_MAJOR) {
> DRM_INFO("VGT interface version mismatch!\n");
> return;
> }
>
> - dev_priv->vgpu.caps = __raw_i915_read32(uncore, vgtif_reg(vgt_caps));
> + dev_priv->vgpu.caps = __raw_uncore_read32(uncore, vgtif_reg(vgt_caps));
>
> dev_priv->vgpu.active = true;
> DRM_INFO("Virtual GPU for Intel GVT-g detected.\n");
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 1816eeae3ba9..3f74889c4212 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -31,7 +31,7 @@
> #define FORCEWAKE_ACK_TIMEOUT_MS 50
> #define GT_FIFO_TIMEOUT_MS10
>
> -#define __raw_posting_read(uncore__, reg__)
> (void)__raw_i915_read32((uncore__), (reg__))
> +#define __raw_posting_read(...) ((void)__raw_uncore_read32(__VA_ARGS__))
Now the person trying to figure out what __raw_posting_read() does will
have to chase __raw_uncore_read32(), which is not even greppable. I'm
not sure this is an improvement to our codebase, bu
Re: [Intel-gfx] [PATCH 2/9] drm/i915: add HAS_FORCEWAKE flag to uncore
Em seg, 2019-03-25 às 14:49 -0700, Daniele Ceraolo Spurio escreveu:
> We have several cases where we don't have forcewake (older gens, GVT and
> planned display-only uncore), so, instead of checking every time against
> the various condition, save the info in a flag and use that.
>
> Note that this patch also change the behavior for gen5 with vpgu
> enabled, but this is not an issue since we don't support vgpu on gen5.
>
> v2: split out from previous path, fix check for missing case (Paulo)
Much better as a separate patch. Thanks.
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 31 +++--
> drivers/gpu/drm/i915/intel_uncore.h | 3 +++
> 2 files changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 3f74889c4212..0259a61a745f 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1391,7 +1391,7 @@ static void intel_uncore_fw_domains_init(struct
> intel_uncore *uncore)
> {
> struct drm_i915_private *i915 = uncore_to_i915(uncore);
>
> - if (INTEL_GEN(i915) <= 5 || intel_vgpu_active(i915))
> + if (!(uncore->flags & UNCORE_HAS_FORCEWAKE))
> return;
>
> if (INTEL_GEN(i915) >= 11) {
> @@ -1590,6 +1590,9 @@ int intel_uncore_init(struct intel_uncore *uncore)
>
> i915_check_vgpu(i915);
>
> + if (INTEL_GEN(i915) > 5 && !intel_vgpu_active(i915))
> + uncore->flags |= UNCORE_HAS_FORCEWAKE;
> +
> intel_uncore_edram_detect(i915);
> intel_uncore_fw_domains_init(uncore);
> __intel_uncore_early_sanitize(uncore, 0);
> @@ -1598,12 +1601,14 @@ int intel_uncore_init(struct intel_uncore *uncore)
> uncore->pmic_bus_access_nb.notifier_call =
> i915_pmic_bus_access_notifier;
>
> - if (IS_GEN_RANGE(i915, 2, 4) || intel_vgpu_active(i915)) {
> - ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen2);
> - ASSIGN_READ_MMIO_VFUNCS(uncore, gen2);
> - } else if (IS_GEN(i915, 5)) {
> - ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen5);
> - ASSIGN_READ_MMIO_VFUNCS(uncore, gen5);
> + if (!(uncore->flags & UNCORE_HAS_FORCEWAKE)) {
> + if (IS_GEN(i915, 5)) {
> + ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen5);
> + ASSIGN_READ_MMIO_VFUNCS(uncore, gen5);
> + } else {
> + ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen2);
> + ASSIGN_READ_MMIO_VFUNCS(uncore, gen2);
> + }
> } else if (IS_GEN_RANGE(i915, 6, 7)) {
> ASSIGN_WRITE_MMIO_VFUNCS(uncore, gen6);
>
> @@ -1912,7 +1917,10 @@ intel_uncore_forcewake_for_read(struct
> drm_i915_private *dev_priv,
> } else if (INTEL_GEN(dev_priv) >= 6) {
> fw_domains = __gen6_reg_read_fw_domains(uncore, offset);
> } else {
> - WARN_ON(!IS_GEN_RANGE(dev_priv, 2, 5));
> + /* on devices with FW we expect to hit one of the above cases */
> + if (unlikely(uncore->flags & UNCORE_HAS_FORCEWAKE))
> + MISSING_CASE(INTEL_GEN(dev_priv));
> +
> fw_domains = 0;
> }
>
> @@ -1938,7 +1946,10 @@ intel_uncore_forcewake_for_write(struct
> drm_i915_private *dev_priv,
> } else if (IS_GEN_RANGE(dev_priv, 6, 7)) {
> fw_domains = FORCEWAKE_RENDER;
> } else {
> - WARN_ON(!IS_GEN_RANGE(dev_priv, 2, 5));
> + /* on devices with FW we expect to hit one of the above cases */
> + if (unlikely(uncore->flags & UNCORE_HAS_FORCEWAKE))
> + MISSING_CASE(INTEL_GEN(dev_priv));
> +
> fw_domains = 0;
> }
>
> @@ -1969,7 +1980,7 @@ intel_uncore_forcewake_for_reg(struct drm_i915_private
> *dev_priv,
>
> WARN_ON(!op);
>
> - if (intel_vgpu_active(dev_priv))
> + if (!(dev_priv->uncore.flags & UNCORE_HAS_FORCEWAKE))
> return 0;
>
> if (op & FW_REG_READ)
> diff --git a/drivers/gpu/drm/i915/intel_uncore.h
> b/drivers/gpu/drm/i915/intel_uncore.h
> index f7670cbc41c9..4947542c6ea7 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.h
> +++ b/drivers/gpu/drm/i915/intel_uncore.h
> @@ -127,6 +127,9 @@ struct intel_uncore {
> } user_forcewake;
>
> int unclaimed_mmio_check;
> +
> + u32 flags;
> +#define UNCORE_HAS_FORCEWAKE BIT(0)
> };
>
> /* Iterate over initialised fw domains */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] drm/i915: add uncore flags for unclaimed mmio
Em seg, 2019-03-25 às 14:49 -0700, Daniele Ceraolo Spurio escreveu:
> Save the HW capabilities to avoid having to jump back to dev_priv
> every time.
>
Reviewed-by: Paulo Zanoni
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Paulo Zanoni
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.c | 4 +-
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_hangcheck.c| 2 +-
> drivers/gpu/drm/i915/intel_uncore.c | 57 ++-
> drivers/gpu/drm/i915/intel_uncore.h | 7 ++-
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 15 ++---
> 6 files changed, 47 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5465b99b4392..85e80701a4c6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2854,7 +2854,7 @@ static int intel_runtime_suspend(struct device *kdev)
> enable_rpm_wakeref_asserts(dev_priv);
> intel_runtime_pm_cleanup(dev_priv);
>
> - if (intel_uncore_arm_unclaimed_mmio_detection(dev_priv))
> + if (intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore))
> DRM_ERROR("Unclaimed access detected prior to suspending\n");
>
> dev_priv->runtime_pm.suspended = true;
> @@ -2908,7 +2908,7 @@ static int intel_runtime_resume(struct device *kdev)
>
> intel_opregion_notify_adapter(dev_priv, PCI_D0);
> dev_priv->runtime_pm.suspended = false;
> - if (intel_uncore_unclaimed_mmio(dev_priv))
> + if (intel_uncore_unclaimed_mmio(&dev_priv->uncore))
> DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
>
> if (INTEL_GEN(dev_priv) >= 11) {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 008560ef4db0..9a9b78c120b1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13533,7 +13533,7 @@ static void intel_atomic_commit_tail(struct
> drm_atomic_state *state)
>* so enable debugging for the next modeset - and hope we catch
>* the culprit.
>*/
> - intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
> + intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore);
> intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET,
> wakeref);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index 57ed49dc19c4..125662c64934 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -270,7 +270,7 @@ static void i915_hangcheck_elapsed(struct work_struct
> *work)
>* periodically arm the mmio checker to see if we are triggering
>* any invalid access.
>*/
> - intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
> + intel_uncore_arm_unclaimed_mmio_detection(&dev_priv->uncore);
>
> for_each_engine(engine, dev_priv, id) {
> struct hangcheck hc;
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 0259a61a745f..1a327828f220 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -509,18 +509,17 @@ gen6_check_for_fifo_debug(struct intel_uncore *uncore)
> }
>
> static bool
> -check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
> +check_for_unclaimed_mmio(struct intel_uncore *uncore)
> {
> - struct intel_uncore *uncore = &dev_priv->uncore;
> bool ret = false;
>
> - if (HAS_FPGA_DBG_UNCLAIMED(dev_priv))
> + if (uncore->flags & UNCORE_HAS_FPGA_DBG_UNCLAIMED)
> ret |= fpga_check_for_unclaimed_mmio(uncore);
>
> - if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + if (uncore->flags & UNCORE_HAS_DBG_UNCLAIMED)
> ret |= vlv_check_for_unclaimed_mmio(uncore);
>
> - if (IS_GEN_RANGE(dev_priv, 6, 7))
> + if (uncore->flags & UNCORE_HAS_FIFO)
> ret |= gen6_check_for_fifo_debug(uncore);
>
> return ret;
> @@ -529,14 +528,12 @@ check_for_unclaimed_mmio(struct drm_i915_private
> *dev_priv)
> static void __intel_uncore_early_sanitize(struct intel_uncore *uncore,
> unsigned int restore_forcewake)
> {
> - struct drm_i915_private *i915 = uncore_to_i915(uncore);
> -
> /* clear out unclaimed reg detection bit */
> - if (check_for_unclaimed_mmio
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Add checks specific to async flips
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
> Support added only for async flips on primary plane.
> If flip is requested on any other plane, reject it.
>
> Make sure there is no change in fbc, offset and framebuffer modifiers
> when async flip is requested.
>
> If any of these are modified, reject async flip.
>
> v2: -Replace DRM_ERROR (Paulo)
> -Add check for changes in OFFSET, FBC, RC(Paulo)
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 59
> 1 file changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a5203de24045..ac7f26a9ac4a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14669,6 +14669,57 @@ static bool
> intel_cpu_transcoders_need_modeset(struct intel_atomic_state *state,
> return false;
> }
>
> +static int intel_atomic_check_async(struct intel_atomic_state *state)
> +{
> + struct drm_plane *plane;
> + struct drm_plane_state *plane_state;
> + struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> + struct intel_plane_state *new_plane_state, *old_plane_state;
> + struct intel_crtc *crtc;
> + struct intel_plane *intel_plane;
> + int i, j;
> +
> + /*FIXME: Async flip is only supported for primary plane currently
> + * Support for overlays to be added.
> + */
> +
> + /*TODO: Check if the user space can handle the EINVAL return
> + * or if it needs to be handled differently
> + */
Does this mean we still didn't test the series against real user space?
I mean, X server with xf86-video-modesetting and some real workload
instead of just igt. I can't feel confident to give r-b tags if I know
the patches were not tested yet. The series should probably have been
marked as an RFC.
> + for_each_new_plane_in_state(&state->base, plane, plane_state, j) {
> + if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
> + DRM_DEBUG_KMS("Async flips is NOT supported for
> non-primary plane\n");
> + return -EINVAL;
> + }
> + }
> +
> + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> + new_crtc_state, i) {
> + if (old_crtc_state->enable_fbc != new_crtc_state->enable_fbc) {
> + DRM_DEBUG_KMS("FBC status cannot be changed in async
> flip\n");
> + return -EINVAL;
> + }
> + }
> +
> + for_each_oldnew_intel_plane_in_state(state, intel_plane,
> old_plane_state,
> + new_plane_state, i) {
> + if ((old_plane_state->color_plane[0].x !=
> + new_plane_state->color_plane[0].x) ||
> + (old_plane_state->color_plane[0].y !=
> + new_plane_state->color_plane[0].y)) {
> + DRM_DEBUG_KMS("Offsets cannot be changed in async\n");
> + return -EINVAL;
> + }
> +
> + if (old_plane_state->uapi.fb->modifier !=
> + new_plane_state->uapi.fb->modifier) {
> + DRM_DEBUG_KMS("Framebuffer modifiers cannot be changed
> in async flip\n");
> + return -EINVAL;
> + }
> + }
> + return 0;
> +}
> +
> /**
> * intel_atomic_check - validate state object
> * @dev: drm device
> @@ -14697,6 +14748,14 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip) {
> + ret = intel_atomic_check_async(state);
> + if (ret)
> + goto fail;
> + }
> + }
> +
> for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> if (!needs_modeset(new_crtc_state)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Enable async flips in i915
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu: > Enable asynchronous flips in i915 for gen9+ platforms. > > v2: -Async flip enablement should be a stand alone patch (Paulo) ... and at the very end of the series. If someone is bisecting the Kernel for some problem unrelated to async flips, and they end up exactly at this commit, and their user space happens to try to do async flips, will their system be broken? A quick check at patches 4, 5 and 6 suggests they are necessary for the feature to work, so here we're enabling a feature that we know won't work because its support is not fully merged yet. A patch series is not allowed to break the Kernel in the middle and then fix it later. > > Signed-off-by: Karthik B S > --- > drivers/gpu/drm/i915/display/intel_display.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index cf8f5779dee4..8601b159f425 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -17574,6 +17574,9 @@ static void intel_mode_config_init(struct > drm_i915_private *i915) > > mode_config->funcs = &intel_mode_funcs; > > + if (INTEL_GEN(i915) >= 9) > + mode_config->async_page_flip = true; > + > /* >* Maximum framebuffer dimensions, chosen to match >* the maximum render engine surface size on gen4+. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Add enable/disable flip done and flip done handler
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
>
> Enable the flip done interrupt in IER.
>
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
>
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
>
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
> flips without pageflip events.
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 7 +++
> drivers/gpu/drm/i915/i915_irq.c | 51
> drivers/gpu/drm/i915/i915_irq.h | 2 +
> 3 files changed, 60 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index bae1d89875d6..3ce80634d047 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15391,6 +15391,13 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> if (state->modeset)
> icl_dbuf_slice_pre_update(state);
>
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip) {
> + skl_enable_flip_done(&crtc->base);
> + break;
> + }
> + }
> +
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> dev_priv->display.commit_modeset_enables(state);
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 1502ab44f1a5..9b64ed78523e 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1253,6 +1253,22 @@ display_pipe_crc_irq_handler(struct drm_i915_private
> *dev_priv,
>u32 crc4) {}
> #endif
>
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> + unsigned int pipe)
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_device *dev = &dev_priv->drm;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev->event_lock, irqflags);
> +
> + drm_crtc_send_vblank_event(&crtc->base, crtc_state->event);
> + crtc_state->event = NULL;
> +
> + spin_unlock_irqrestore(&dev->event_lock, irqflags);
> + skl_disable_flip_done(&crtc->base);
I am trying to understand the code here but I'm not 100% confident, so
my comments may be wrong. Please correct me if needed.
Can you please elaborate on why we have to disable the interrupt from
the interrupt handler? This looks racy to me, but I may be wrong, so an
explanation would help.
In my head this would be the ideal:
- If the whole ioctl is blocked until we get the interrupt (which is
what patch 04 suggests), then whatever is blocking waiting on the
interrupt should enable+disable the interrupt (so no disable_flip_done
here).
- If the ioctl is not blocked, then isn't there a race risk in case
user space finds a way to submit 2 ioctls before we get an interrupt?
If no, why would this be impossible? Some sort of refcounting could
help in this case. I'm also thinking in cases like alternating between
flips requiring events and flips not requiring events.
> +}
>
> static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>enum pipe pipe)
> @@ -2355,6 +2371,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
> u32 master_ctl)
> if (iir & GEN8_PIPE_VBLANK)
> intel_handle_vblank(dev_priv, pipe);
>
> + if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
> + flip_done_handler(dev_priv, pipe);
> +
> if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
> hsw_pipe_crc_irq_handler(dev_priv, pipe);
>
> @@ -2636,6 +2655,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
> return 0;
> }
>
> +void skl_enable_flip_done(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> +
> + bdw_enable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
> +
> + spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> +}
> +
> /* Called f
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915: Make commit call blocking in case of async flips
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
> Make the commit call blocking in case of async flips
> so that there is no delay in completing the flip.
>
I'm trying to understand the code. Can you please elaborate more here
in this commit message? Why exactly does the call need to block? What
would be the problem of not having this patch? And how does blocking
ensures no delay?
> v2: -Rebased
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8601b159f425..a5203de24045 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15563,7 +15563,9 @@ static int intel_atomic_commit(struct drm_device *dev,
> {
> struct intel_atomic_state *state = to_intel_atomic_state(_state);
> struct drm_i915_private *dev_priv = to_i915(dev);
> - int ret = 0;
> + struct intel_crtc_state *new_crtc_state;
> + struct intel_crtc *crtc;
> + int ret = 0, i;
>
> state->wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
>
> @@ -15589,10 +15591,6 @@ static int intel_atomic_commit(struct drm_device
> *dev,
>* (assuming we had any) would solve these problems.
>*/
> if (INTEL_GEN(dev_priv) < 9 && state->base.legacy_cursor_update) {
> - struct intel_crtc_state *new_crtc_state;
> - struct intel_crtc *crtc;
> - int i;
> -
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
> if (new_crtc_state->wm.need_postvbl_update ||
> new_crtc_state->update_wm_post)
> @@ -15634,6 +15632,13 @@ static int intel_atomic_commit(struct drm_device
> *dev,
> drm_atomic_state_get(&state->base);
> INIT_WORK(&state->base.commit_work, intel_atomic_commit_work);
>
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip) {
> + nonblock = false;
> + break;
> + }
> + }
> +
> i915_sw_fence_commit(&state->commit_ready);
> if (nonblock && state->modeset) {
> queue_work(dev_priv->modeset_wq, &state->base.commit_work);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/5] Asynchronous flip implementation for i915
Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu: > Without async flip support in the kernel, fullscreen apps where game > resolution is equal to the screen resolution, must perform an extra blit > per frame prior to flipping. > > Asynchronous page flips will also boost the FPS of Mesa benchmarks. > > v2: Few patches have been squashed and patches have been shuffled as > per the reviews on the previous version. > > v3: Few patches have been squashed and patches have been shuffled as > per the reviews on the previous version. Hello I asked quite a few questions in the review of v2, but never got any replies. I see some things regarding those questions are different in v3, but I still would really like to have those answers in direct text/email form in order to clarify my understanding of your original intent (and also help me understand why things are different in v3). Would you mind replying to those emails? Thanks, Paulo > > Karthik B S (5): > drm/i915: Add enable/disable flip done and flip done handler > drm/i915: Add support for async flips in I915 > drm/i915: Add checks specific to async flips > drm/i915: Do not call drm_crtc_arm_vblank_event in async flips > drm/i915: Enable async flips in i915 > > drivers/gpu/drm/i915/display/intel_display.c | 71 > drivers/gpu/drm/i915/display/intel_sprite.c | 8 ++- > drivers/gpu/drm/i915/i915_irq.c | 52 ++ > drivers/gpu/drm/i915/i915_irq.h | 2 + > drivers/gpu/drm/i915/i915_reg.h | 1 + > 5 files changed, 133 insertions(+), 1 deletion(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Add enable/disable flip done and flip done handler
Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
>
> Enable the flip done interrupt in IER.
>
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
>
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
>
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
> flips without pageflip events.
>
> v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
> -Make the pending vblank event NULL in the begining of
> flip_done_handler to remove sporadic WARN_ON that is seen.
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 10
> drivers/gpu/drm/i915/i915_irq.c | 52
> drivers/gpu/drm/i915/i915_irq.h | 2 +
> 3 files changed, 64 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f40b909952cc..48cc1fc9bc5a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15530,6 +15530,13 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>
> intel_dbuf_pre_plane_update(state);
>
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip) {
> + skl_enable_flip_done(&crtc->base);
> + break;
> + }
> + }
> +
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> dev_priv->display.commit_modeset_enables(state);
>
> @@ -15551,6 +15558,9 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> drm_atomic_helper_wait_for_flip_done(dev, &state->base);
>
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_disable_flip_done(&crtc->base);
> +
> if (new_crtc_state->hw.active &&
> !needs_modeset(new_crtc_state) &&
> !new_crtc_state->preload_luts &&
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index efdd4c7b8e92..632e7b1deb87 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1295,6 +1295,23 @@ display_pipe_crc_irq_handler(struct drm_i915_private
> *dev_priv,
>u32 crc4) {}
> #endif
>
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> + unsigned int pipe)
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_pending_vblank_event *e = crtc_state->event;
> + struct drm_device *dev = &dev_priv->drm;
> + unsigned long irqflags;
> +
> + crtc_state->event = NULL;
> +
> + spin_lock_irqsave(&dev->event_lock, irqflags);
> +
> + drm_crtc_send_vblank_event(&crtc->base, e);
I don't think this is what we want. With this, the events the Kernel
sends us all have the same sequence and timestamp. In fact, the IGT
test you submitted fails because of this.
In my original hackish proof-of-concept patch I had changed
drm_update_vblank_count() to force diff=1 in order to always send
events and I also changed g4x_get_vblank_counter() to get the counter
from FLIPCOUNT (which updates every time there's a flip) instead of
FRMCOUNT (which doesn't seem to increment when you do async flips).
That is a drastic change, but the patch was just a PoC so I didn't care
about keeping anything else working.
One thing that confused me a little bit when dealing the the
vblank/flip event interface from drm.ko is that "flips" and "vblanks"
seem to be changed interchangeably, which is confusing for async flips:
if you keep forever doing async flips in the very first few scanlines
you never actually reach the "vblank" period, yet you keep flipping
your frame. Then, what should your expectation regarding events be?
I think we may need to check how the other drivers handle async vblanks
(or how drm.ko wants us to handle async vblanks). Should we increment
sequence on every async flip? What about the timestamp?
Daniel, Ville, do you happen to know the proper semantics here?
There's certainly some adjustment to do to both this patch and the
Re: [Intel-gfx] [PATCH v5 0/5] Asynchronous flip implementation for i915
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu: > Without async flip support in the kernel, fullscreen apps where game > resolution is equal to the screen resolution, must perform an extra blit > per frame prior to flipping. > > Asynchronous page flips will also boost the FPS of Mesa benchmarks. We had a discussion in patch 1 of v3 regarding the semantics of asynchronous flips from the point of view of the user space: how we handle our vblank counters, how/when we increment the sequence events and how we handle timestamps, how/when we deliver vblank events. Since apparently AMD has already enabled this feature, our job would be to implement their current behavior so KMS clients can continue to work regardless of the driver. From reading this series it's not super clear to me what exactly is the behavior that we're trying to follow. Can you please document somewhere what are these rules and expectations? This way, people writing user space code (or people improving the other drivers) will have an easier time. In addition to text documentation, I believe all our assumptions and rules should be coded in IGT: we want to be confident a driver implements async page flips correctly when we can verify it passes the IGT. Also, in the other patches I raise some additional questions regarding mixing async with non-async vblanks: IMHO this should also be documented as text and as IGT. > > v2: -Few patches have been squashed and patches have been shuffled as > per the reviews on the previous version. > > v3: -Few patches have been squashed and patches have been shuffled as > per the reviews on the previous version. > > v4: -Made changes to fix the sequence and time stamp issue as per the > comments received on the previous version. > -Timestamps are calculated using the flip done time stamp and current > timestamp. Here I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag is used > for timestamp calculations. > -Event is sent from the interrupt handler immediately using this > updated timestamps and sequence. > -Added more state checks as async flip should only allow change in plane > surface address and nothing else should be allowed to change. > -Added a separate plane hook for async flip. > -Need to find a way to reject fbc enabling if it comes as part of this > flip as bspec states that changes to FBC are not allowed. > > v5: -Fixed the Checkpatch and sparse warnings. > > Karthik B S (5): > drm/i915: Add enable/disable flip done and flip done handler > drm/i915: Add support for async flips in I915 > drm/i915: Add checks specific to async flips > drm/i915: Do not call drm_crtc_arm_vblank_event in async flips > drm/i915: Enable async flips in i915 > > drivers/gpu/drm/i915/display/intel_display.c | 123 +++ > drivers/gpu/drm/i915/display/intel_sprite.c | 33 - > drivers/gpu/drm/i915/i915_irq.c | 83 +++-- > drivers/gpu/drm/i915/i915_irq.h | 2 + > drivers/gpu/drm/i915/i915_reg.h | 5 +- > 5 files changed, 237 insertions(+), 9 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 2/5] drm/i915: Add support for async flips in I915
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> Set the Async Address Update Enable bit in plane ctl
> when async flip is requested.
>
> v2: -Move the Async flip enablement to individual patch (Paulo)
>
> v3: -Rebased.
>
> v4: -Add separate plane hook for async flip case (Ville)
>
> v5: -Rebased.
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 6 +
> drivers/gpu/drm/i915/display/intel_sprite.c | 25
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 3 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b8ff032195d9..4773f39e5924 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4766,6 +4766,12 @@ u32 skl_plane_ctl(const struct intel_crtc_state
> *crtc_state,
> const struct drm_intel_sprite_colorkey *key = &plane_state->ckey;
> u32 plane_ctl;
>
> + /* During Async flip, no other updates are allowed */
My understanding is that this function is fully setting the right bits
based on the chosen config (instead of doing read-modify-write), and
the checks for "other updates" were done before. So the logic
implemented here of early returning doesn't make sense.
> + if (crtc_state->uapi.async_flip) {
> + plane_ctl |= PLANE_CTL_ASYNC_FLIP;
I wonder why gcc does not complain we're ORing with an unitialized
value.
> + return plane_ctl;
> + }
> +
> plane_ctl = PLANE_CTL_ENABLE;
It seems to be the return above means we'll never even try to enable
the plane, we're only relying on the fact that plane_ctl is not zero
initialize so maybe bit 31 is already set.
>
> if (INTEL_GEN(dev_priv) < 10 && !IS_GEMINILAKE(dev_priv)) {
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index c26ca029fc0a..3747482e8fa3 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -603,6 +603,24 @@ icl_program_input_csc(struct intel_plane *plane,
> PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
> }
>
> +static void
> +skl_program_async_surface_address(struct drm_i915_private *dev_priv,
> + const struct intel_plane_state *plane_state,
> + enum pipe pipe, enum plane_id plane_id,
> + u32 surf_addr)
> +{
> + unsigned long irqflags;
> + u32 plane_ctl = plane_state->ctl;
> +
> + spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
> +
> + intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
> + intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
> + intel_plane_ggtt_offset(plane_state) + surf_addr);
> +
> + spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
> +}
> +
> static void
> skl_program_plane(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state,
> @@ -631,6 +649,13 @@ skl_program_plane(struct intel_plane *plane,
> u32 keymsk, keymax;
> u32 plane_ctl = plane_state->ctl;
>
> + /* During Async flip, no other updates are allowed */
> + if (crtc_state->uapi.async_flip) {
> + skl_program_async_surface_address(dev_priv, plane_state,
> + pipe, plane_id, surf_addr);
> + return;
> + }
I'd vote for us to keep the "don't rewrite registers that shouldn't
change" part on its own commit, since it's just an optimization. It
could even go at the end of the series. But perhaps this is simple
enough and not needed.
> +
> plane_ctl |= skl_plane_ctl_crtc(crtc_state);
>
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8cee06314d5d..19aad4199874 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6935,6 +6935,7 @@ enum {
> #define PLANE_CTL_TILED_X (1 << 10)
> #define PLANE_CTL_TILED_Y (4 << 10)
> #define PLANE_CTL_TILED_YF (5 << 10)
> +#define PLANE_CTL_ASYNC_FLIP (1 << 9)
> #define PLANE_CTL_FLIP_HORIZONTAL (1 << 8)
> #define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */
> #define PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
> Add enable/disable flip done functions and the flip done handler
> function which handles the flip done interrupt.
>
> Enable the flip done interrupt in IER.
>
> Enable flip done function is called before writing the
> surface address register as the write to this register triggers
> the flip done interrupt
>
> Flip done handler is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
> The interrupt is disabled after the event is sent.
>
> v2: -Change function name from icl_* to skl_* (Paulo)
> -Move flip handler to this patch (Paulo)
> -Remove vblank_put() (Paulo)
> -Enable flip done interrupt for gen9+ only (Paulo)
> -Enable flip done interrupt in power_well_post_enable hook (Paulo)
> -Removed the event check in flip done handler to handle async
> flips without pageflip events.
>
> v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
> -Make the pending vblank event NULL in the beginning of
> flip_done_handler to remove sporadic WARN_ON that is seen.
>
> v4: -Calculate timestamps using flip done time stamp and current
> timestamp for async flips (Ville)
>
> v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
> static.(Reported-by: kernel test robot )
> -Fix the typo in commit message.
>
> Signed-off-by: Karthik B S
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 10 +++
> drivers/gpu/drm/i915/i915_irq.c | 83 ++--
> drivers/gpu/drm/i915/i915_irq.h | 2 +
> drivers/gpu/drm/i915/i915_reg.h | 4 +-
> 4 files changed, 91 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index db2a5a1a9b35..b8ff032195d9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -15562,6 +15562,13 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>
> intel_dbuf_pre_plane_update(state);
>
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip) {
> + skl_enable_flip_done(&crtc->base);
> + break;
Do we really want the break here? What if more than one CRTC wants an
async flip?
Perhaps you could extend IGT to try this.
> + }
> + }
> +
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> dev_priv->display.commit_modeset_enables(state);
>
> @@ -15583,6 +15590,9 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> drm_atomic_helper_wait_for_flip_done(dev, &state->base);
>
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> + if (new_crtc_state->uapi.async_flip)
> + skl_disable_flip_done(&crtc->base);
Here we don't break in the first found, so at least there's an
inconsistency.
> +
> if (new_crtc_state->hw.active &&
> !needs_modeset(new_crtc_state) &&
> !new_crtc_state->preload_luts &&
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 1fa67700d8f4..95953b393941 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -697,14 +697,24 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
> return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
> }
>
> +static u32 g4x_get_flip_counter(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> +
> + return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
> +}
> +
> u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> enum pipe pipe = to_intel_crtc(crtc)->pipe;
>
> + if (crtc->state->async_flip)
> + return g4x_get_flip_counter(crtc);
> +
> return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
I don't understand the intention behind this, can you please clarify?
This goes back to my reply of the cover letter. It seems that here
we're going to alternate between two different counters in our vblank
count. So if user space alternates between sometimes using async flips
and sometimes using normal flip it's going to get some very weird
deltas, isn't it? At least this is what I remember from when I played
with these registers: FLIPCOUNT drifts away from FRMCOUNT when we start
using async flips.
IMHO we really need our IGT to exercise this possibility.
> }
> -
Don't remove this blank line, please.
> /*
> * On certain encoders on certain platforms, pipe
> * scanline register will not work to get the scanline,
> @@ -737,17 +747,24 @@
Re: [Intel-gfx] [RFC 1/7] drm/i915: Define flip done functions and enable IER
Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Add enable/disable flip done functions and enable
> the flip done interrupt in IER.
>
> Flip done interrupt is used to send the page flip event as soon as the
> surface address is written as per the requirement of async flips.
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/i915_irq.c | 37 -
> drivers/gpu/drm/i915/i915_irq.h | 2 ++
> 2 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index ecf07b0faad2..5955e737a45d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2626,6 +2626,27 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
> return 0;
> }
>
> +void icl_enable_flip_done(struct drm_crtc *crtc)
Platform prefixes indicate the first platform that is able to run this
function. In this case I can't even see which platforms will run the
function because it's only later in the series that this function will
get called. I'm not a fan of this patch splitting style where a
function gets added in patch X and then used in patch X+Y. IMHO
functions should only be introduced in patches where they are used.
This makes the code much easier to review.
So, shouldn't this be skl_enable_flip_done()?
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + struct drm_vblank_crtc *vblank = &dev_priv->drm.vblank[pipe];
> + unsigned long irqflags;
> +
> + /* Make sure that vblank is not enabled, as we are already sending
> + * the page flip event in the flip_done_handler.
> + */
> + if (atomic_read(&vblank->refcount) != 0)
> + drm_crtc_vblank_put(crtc);
This is the kind of thing that will be much easier to review when this
patch gets squashed in the one that makes use of these functions.
Even after reading the whole series, this put() doesn't seem correct to
me. What is the problem with having vblanks enabled? Is it because we
were sending duplicate vblank events without these lines? Where is the
get() that triggers this put()? Please help me understand this.
> +
> + spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> +
> + bdw_enable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
> +
> + spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> +
> +}
> +
> /* Called from drm generic code, passed 'crtc' which
> * we use as a pipe index
> */
> @@ -2686,6 +2707,20 @@ void bdw_disable_vblank(struct drm_crtc *crtc)
> spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> }
>
> +
> +void icl_disable_flip_done(struct drm_crtc *crtc)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
> +
> + bdw_disable_pipe_irq(dev_priv, pipe, GEN9_PIPE_PLANE1_FLIP_DONE);
> +
> + spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
> +}
> +
> static void ibx_irq_reset(struct drm_i915_private *dev_priv)
> {
> struct intel_uncore *uncore = &dev_priv->uncore;
> @@ -3375,7 +3410,7 @@ static void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
> de_port_masked |= CNL_AUX_CHANNEL_F;
>
> de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
> -GEN8_PIPE_FIFO_UNDERRUN;
> + GEN8_PIPE_FIFO_UNDERRUN | GEN9_PIPE_PLANE1_FLIP_DONE;
This is going to set this bit for gen8 too, which is something we
probably don't want since it doesn't exist there.
The patch also does not add the handler for the interrupt, which
doesn't make sense (see my point above).
Also, don't we want to do like GEN8_PIPE_VBLANK and also set it on the
power_well_post_enable hook? If not, why? This is probably a case we
should write an IGT subtest for.
>
> de_port_enables = de_port_masked;
> if (IS_GEN9_LP(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
> index 812c47a9c2d6..6fc319980dd3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.h
> +++ b/drivers/gpu/drm/i915/i915_irq.h
> @@ -114,11 +114,13 @@ int i915gm_enable_vblank(struct drm_crtc *crtc);
> int i965_enable_vblank(struct drm_crtc *crtc);
> int ilk_enable_vblank(struct drm_crtc *crtc);
> int bdw_enable_vblank(struct drm_crtc *crtc);
> +void icl_enable_flip_done(struct drm_crtc *crtc);
> void i8xx_disable_vblank(struct drm_crtc *crtc);
> void i915gm_disable_vblank(struct drm_crtc *crtc);
> void i965_disable_vblank(struct drm_crtc *crtc);
> void ilk_disable_vblank(struct drm_crtc *crtc);
> void bdw_disable_vblank(struct drm_crtc *crtc);
> +void icl_disable_flip_done(struct drm_crtc *crtc);
>
> void gen2_irq_reset(struct intel_uncore *uncore);
> void gen3_irq_reset(struct intel_uncore *uncore, i915_reg_t imr,
Re: [Intel-gfx] [RFC 2/7] drm/i915: Add support for async flips in I915
Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Enable support for async flips in I915.
> Set the Async Address Update Enable bit in plane ctl
> when async flip is requested.
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 4
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index dd47eb65b563..4ce9897f5c58 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4756,6 +4756,9 @@ u32 skl_plane_ctl(const struct intel_crtc_state
> *crtc_state,
> plane_ctl |= PLANE_CTL_YUV_RANGE_CORRECTION_DISABLE;
> }
>
> + if (crtc_state->uapi.async_flip)
> + plane_ctl |= PLANE_CTL_ASYNC_FLIP;
> +
> plane_ctl |= skl_plane_ctl_format(fb->format->format);
> plane_ctl |= skl_plane_ctl_tiling(fb->modifier);
> plane_ctl |= skl_plane_ctl_rotate(rotation & DRM_MODE_ROTATE_MASK);
> @@ -17738,6 +17741,7 @@ static void intel_mode_config_init(struct
> drm_i915_private *i915)
>
> mode_config->funcs = &intel_mode_funcs;
>
> + mode_config->async_page_flip = true;
We should only enable the feature to user space after it has been fully
implemented inside the Kernel. Think about the case where git-bisect
decides to land at exactly this commit when someone is debugging a
failure unrelated to async vblanks.
Also, when features have trivial on/off switches like the line above,
it's better if the patch that enables the feature only contains the
line that toggles the on/off switch. This way, if a revert is needed,
we can just switch it to off without removing more code. Also, it
enables us to land the rest of the code while keeping the feature off
for stabilization.
Also, the line above is enabling the feature for every platform, which
is probably not a goal of this series.
> /*
>* Maximum framebuffer dimensions, chosen to match
>* the maximum render engine surface size on gen4+.
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 80cf02a6eec1..42037aee9b78 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6794,6 +6794,7 @@ enum {
> #define PLANE_CTL_TILED_X (1 << 10)
> #define PLANE_CTL_TILED_Y (4 << 10)
> #define PLANE_CTL_TILED_YF (5 << 10)
> +#define PLANE_CTL_ASYNC_FLIP (1 << 9)
> #define PLANE_CTL_FLIP_HORIZONTAL (1 << 8)
> #define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */
> #define PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/7] drm/i915: Add checks specific to async flips
Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Support added only for async flips on primary plane.
> If flip is requested on any other plane, reject it.
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 29
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 25fad5d01e67..a8de08c3773e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14732,6 +14732,31 @@ static bool
> intel_cpu_transcoders_need_modeset(struct intel_atomic_state *state,
> return false;
> }
>
> +static int intel_atomic_check_async(struct intel_atomic_state *state)
> +{
> + struct drm_plane *plane;
> + struct drm_plane_state *plane_state;
> + struct intel_crtc_state *crtc_state;
> + struct intel_crtc *crtc;
> + int i, j;
> +
> + /*FIXME: Async flip is only supported for primary plane currently
> + * Support for overlays to be added.
> + */
> + for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> + if (crtc_state->uapi.async_flip) {
> + for_each_new_plane_in_state(&state->base,
> + plane, plane_state, j) {
> + if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
> + DRM_ERROR("Async flips is NOT supported
> for non-primary plane\n");
My understanding is that this is not a case of DRM_ERROR, since it's
just user space doing something it shouldn't.
Have we checked if xf86-video-modesetting or some other current user
space is going to try these calls on non-primary when async_flips are
enabled? Specifically, how does it react when it gets the EINVAL? We
should try to avoid the case where we release a Kernel that current
user space is not prepared for (even if it's not the Kernel's fault).
> + return -EINVAL;
> + }
> + }
> + }
> + }
> + return 0;
> +}
> +
> /**
> * intel_atomic_check - validate state object
> * @dev: drm device
> @@ -14760,6 +14785,10 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> + ret = intel_atomic_check_async(state);
> + if (ret)
> + goto fail;
> +
> for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> if (!needs_modeset(new_crtc_state)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 5/7] drm/i915: Add flip_done_handler definition
Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu:
> Send the flip done event in the handler and disable the interrupt.
>
> Signed-off-by: Karthik B S
> ---
> drivers/gpu/drm/i915/i915_irq.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 5955e737a45d..1feda9aecf4a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1243,6 +1243,24 @@ display_pipe_crc_irq_handler(struct drm_i915_private
> *dev_priv,
>u32 crc4) {}
> #endif
>
> +static void flip_done_handler(struct drm_i915_private *dev_priv,
> + unsigned int pipe)
The compiler is going to complain that we added a static function with
no caller.
See my comment on commit 1: please squash this patch with the one that
makes use of the new function.
> +{
> + struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> + struct drm_crtc_state *crtc_state = crtc->base.state;
> + struct drm_device *dev = &dev_priv->drm;
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(&dev->event_lock, irqflags);
> +
> + if (crtc_state->event->base.event->type == DRM_EVENT_FLIP_COMPLETE) {
> + drm_crtc_send_vblank_event(&crtc->base, crtc_state->event);
> + crtc_state->event = NULL;
> + }
> +
> + spin_unlock_irqrestore(&dev->event_lock, irqflags);
> + icl_disable_flip_done(&crtc->base);
> +}
>
> static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
>enum pipe pipe)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/7] Asynchronous flip implementation for i915
Em sex, 2020-03-06 às 17:09 +0530, Karthik B S escreveu: > Without async flip support in the kernel, fullscreen apps where game > resolution is equal to the screen resolution, must perform an extra blit > per frame prior to flipping. > > Asynchronous page flips will also boost the FPS of Mesa benchmarks. Thanks a lot for doing this work! I did some quick smoke tests on a Gemini Lake and while this appears to be working fine with xf86-video-modesetting, the "pageflip.c" program I shared previously breaks when you launch it as "./pageflip -n": this argument makes the program *not* request for page flip events (by not setting DRM_MODE_PAGE_FLIP_EVENT) and just try to flip as fast as it can. I didn't investigate why this breaks, but it's probably some corner case the series is forgetting. Also, doesn't async pageflip interact with some other display features? Don't we need to disable at least one of FBC, PSR and/or render compression when using async page flips? Ville mentioned some possible interactions with SURF/OFFSET tracking too (framebuffers not being at the start of the bo), which doesn't seem to be covered by the series. Thanks, Paulo > > Karthik B S (7): > drm/i915: Define flip done functions and enable IER > drm/i915: Add support for async flips in I915 > drm/i915: Make commit call blocking in case of async flips > drm/i915: Add checks specific to async flips > drm/i915: Add flip_done_handler definition > drm/i915: Enable and handle flip done interrupt > drm/i915: Do not call drm_crtc_arm_vblank_event in async flips > > drivers/gpu/drm/i915/display/intel_display.c | 55 +-- > drivers/gpu/drm/i915/display/intel_sprite.c | 12 ++-- > drivers/gpu/drm/i915/i915_irq.c | 58 +++- > drivers/gpu/drm/i915/i915_irq.h | 2 + > drivers/gpu/drm/i915/i915_reg.h | 1 + > 5 files changed, 117 insertions(+), 11 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: expose command stream timestamp frequency to userspace
Em Sex, 2017-11-10 às 19:08 +, Lionel Landwerlin escreveu:
> We use to have this fixed per generation, but starting with CNL
> userspace
> cannot tell just off the PCI ID. Let's make this information
> available. This
> is particularly useful for performance monitoring where much of the
> normalization work is done using those timestamps (this include
> pipeline
> statistics in both GL & Vulkan as well as OA reports).
>
> v2: Use variables for 24MHz/19.2MHz values (Ewelina)
> Renamed function & coding style (Sagar)
>
> v3: Fix frequency read on Broadwell (Sagar)
> Fix missing divide by 4 on <= gen4 (Sagar)
>
> Signed-off-by: Lionel Landwerlin
> Tested-by: Rafael Antognolli
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +
> drivers/gpu/drm/i915/i915_drv.c | 3 +
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_reg.h | 21 ++
> drivers/gpu/drm/i915/intel_device_info.c | 107
> +++
> include/uapi/drm/i915_drm.h | 6 ++
> 6 files changed, 141 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 533ba096b9a6..57485f29d7c9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3245,6 +3245,8 @@ static int i915_engine_info(struct seq_file *m,
> void *unused)
> yesno(dev_priv->gt.awake));
> seq_printf(m, "Global active requests: %d\n",
> dev_priv->gt.active_requests);
> + seq_printf(m, "CS timestamp frequency: %llu Hz\n",
> + dev_priv->info.cs_timestamp_frequency);
>
> p = drm_seq_file_printer(m);
> for_each_engine(engine, dev_priv, id)
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index d97fe9c9439a..dbd04d5f75ee 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -419,6 +419,9 @@ static int i915_getparam(struct drm_device *dev,
> void *data,
> if (!value)
> return -ENODEV;
> break;
> + case I915_PARAM_CS_TIMESTAMP_FREQUENCY:
> + value = INTEL_INFO(dev_priv)-
> >cs_timestamp_frequency;
> + break;
> default:
> DRM_DEBUG("Unknown parameter %d\n", param->param);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 9f26c34e0e52..ebc49ca58eb7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -885,6 +885,8 @@ struct intel_device_info {
> /* Slice/subslice/EU info */
> struct sseu_dev_info sseu;
>
> + u64 cs_timestamp_frequency;
> +
> struct color_luts {
> u16 degamma_lut_size;
> u16 gamma_lut_size;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 7aa7dc0c336b..ec9faa11e305 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1119,9 +1119,24 @@ static inline bool
> i915_mmio_reg_valid(i915_reg_t reg)
>
> /* RPM unit config (Gen8+) */
> #define RPM_CONFIG0 _MMIO(0x0D00)
> +#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT 3
> +#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK(1 <<
> GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
> +#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ0
> +#define GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ 1
> +#define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT 1
> +#define GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK (0x3 <<
> GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT)
> +
> #define RPM_CONFIG1 _MMIO(0x0D04)
> #define GEN10_GT_NOA_ENABLE (1 << 9)
>
> +/* GPM unit config (Gen9+) */
> +#define CTC_MODE _MMIO(0xA26C)
> +#define CTC_SOURCE_PARAMETER_MASK 1
> +#define CTC_SOURCE_CRYSTAL_CLOCK0
> +#define CTC_SOURCE_DIVIDE_LOGIC 1
> +#define CTC_SHIFT_PARAMETER_SHIFT 1
> +#define CTC_SHIFT_PARAMETER_MASK(0x3 <<
> CTC_SHIFT_PARAMETER_SHIFT)
> +
> /* RCP unit config (Gen8+) */
> #define RCP_CONFIG _MMIO(0x0D08)
>
> @@ -8866,6 +8881,12 @@ enum skl_power_gate {
> #define ILK_TIMESTAMP_HI _MMIO(0x70070)
> #define IVB_TIMESTAMP_CTR_MMIO(0x44070)
>
> +#define GEN9_TIMESTAMP_OVERRIDE _MMIO
> (0x44074)
> +#define GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DIVIDER_SHIFT0
> +#define GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DIVIDER_MASK 0x3f
> f
> +#define GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_SHIFT
> 12
> +#define GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_MASK
> (0xf << 12)
> +
> #define _PIPE_FRMTMSTMP_A0x70048
> #define PIPE_FRMTMSTMP(pipe) \
> _MMIO_PIPE2(pipe, _PIPE_FRMTMSTMP_A)
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index db03d179f
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/cnl: only divide up base frequency with crystal source
Em Seg, 2017-11-13 às 23:34 +, Lionel Landwerlin escreveu:
> We apply this logic to Gen9 as well. We didn't notice this issue as
> most part we've encountered so far only use the crystal as source for
> their timestamp registers.
>
> Fixes: dab9178333 ("drm/i915: expose command stream timestamp
> frequency to userspace")
> Signed-off-by: Lionel Landwerlin
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index f3e4940fed49..039f8ec7ad27 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -413,15 +413,15 @@ static u32 read_timestamp_frequency(struct
> drm_i915_private *dev_priv)
> freq = f24_mhz;
> break;
> }
> - }
>
> - /* Now figure out how the command stream's timestamp
> register
> - * increments from this frequency (it might
> increment only
> - * every few clock cycle).
> - */
> - freq >>= 3 - ((rpm_config_reg &
> - GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER
> _MASK) >>
> - GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_
> SHIFT);
> + /* Now figure out how the command stream's
> timestamp
> + * register increments from this frequency
> (it might
> + * increment only every few clock cycle).
> + */
> + freq >>= 3 - ((rpm_config_reg &
> + GEN10_RPM_CONFIG0_CTC_SHIFT_P
> ARAMETER_MASK) >>
> + GEN10_RPM_CONFIG0_CTC_SHIFT_PA
> RAMETER_SHIFT);
> + }
>
> return freq;
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/cnl: only divide up base frequency with crystal source
Em Seg, 2017-12-04 às 15:50 -0200, Paulo Zanoni escreveu:
> Em Seg, 2017-11-13 às 23:34 +, Lionel Landwerlin escreveu:
> > We apply this logic to Gen9 as well. We didn't notice this issue as
> > most part we've encountered so far only use the crystal as source
> > for
> > their timestamp registers.
> >
> > Fixes: dab9178333 ("drm/i915: expose command stream timestamp
> > frequency to userspace")
> > Signed-off-by: Lionel Landwerlin
>
> Reviewed-by: Paulo Zanoni
I also merged this since I need it.
Patch 3 still needs a check from the people who were reviewing its
previous versions.
>
> > ---
> > drivers/gpu/drm/i915/intel_device_info.c | 16
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index f3e4940fed49..039f8ec7ad27 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > @@ -413,15 +413,15 @@ static u32 read_timestamp_frequency(struct
> > drm_i915_private *dev_priv)
> > freq = f24_mhz;
> > break;
> > }
> > - }
> >
> > - /* Now figure out how the command stream's
> > timestamp
> > register
> > - * increments from this frequency (it might
> > increment only
> > - * every few clock cycle).
> > - */
> > - freq >>= 3 - ((rpm_config_reg &
> > - GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMET
> > ER
> > _MASK) >>
> > - GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETE
> > R_
> > SHIFT);
> > + /* Now figure out how the command stream's
> > timestamp
> > + * register increments from this frequency
> > (it might
> > + * increment only every few clock cycle).
> > + */
> > + freq >>= 3 - ((rpm_config_reg &
> > + GEN10_RPM_CONFIG0_CTC_SHIFT
> > _P
> > ARAMETER_MASK) >>
> > + GEN10_RPM_CONFIG0_CTC_SHIFT_
> > PA
> > RAMETER_SHIFT);
> > + }
> >
> > return freq;
> > }
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v8] tests/kms_frontbuffer_tracking: Including DRRS test coverage
Em Qua, 2017-12-06 às 20:43 +0530, Lohith BS escreveu:
> Dynamic Refresh Rate Switch(DRRS) is used to switch the panel's
> refresh rate to the lowest vrefresh supported by panel, when frame is
> not flipped for more than a Sec.
>
> In kernel, DRRS uses the front buffer tracking infrastructure.
> Hence DRRS test coverage is added along with other frontbuffer
> tracking
> based features such as FBC and PSR tests.
>
> Here, we are testing DRRS with other features in all possible
> combinations, in all required test cases, to capture any possible
> regression.
>
> v2: Addressed the comments and suggestions from Vlad, Marius.
> The signoff details from the earlier work are also included.
>
> v3: Modified vblank rate calculation by using reply-sequence,
> provided by drmWaitVBlank, as suggested by Chris Wilson.
>
> v4: As suggested from Chris Wilson and Daniel Vetter
> 1) Avoided using pthread for calculating vblank refresh rate,
> instead used drmWaitVBlank reply sequence.
> 2) Avoided using kernel-specific info like transitional delays,
> instead polling mechanism with timeout is used.
> 3) Included edp-DRRS as a subtest in kms_frontbuffer_tracking.c,
> instead of having a separate test.
>
> v5: This patch adds DRRS as a new feature in the
> kms_frontbuffer_tracking IGT.
> DRRS switch to lower vrefresh rate is tested at slow-draw
> subtest.
>
> Note:
> 1) Currently kernel doesn't have support to enable and disable
> the DRRS feature dynamically(as in case of PSR). Hence if the
> panel supports DRRS it will be enabled by default.
>
> This is in continuation of last patch
> "https://patchwork.freedesktop.org/patch/162726/";
>
> v6: This patch adds runtime enable and disable feature for testing
> DRRS
>
> v7: This patch adds runtime enable and disable feature for testing
> DRRS
> through debugfs entry "i915_drrs_ctl".
>
> v8: Commit message is updated to reflect current implementation.
Not a full review, but: coding style and indentation needs to be fixed.
There are a few chunks where the only thing the patch does is make
indentation wrong.
There are chunks that only add blank lines.
There are chunks that leave functions without empty lines between them.
There are chunks that add code that do not follow the coding style used
by the rest of the file (which is the same style used by the Kernel).
There are chunks that use white spaces in places where tabs should be
used.
Please review your own patch before we can review it.
FEATURE_COUNT needs to be 8. Any undesired combinations need explicit
code to avoid them with a nice comment explaining why.
>
> Signed-off-by: Lohith BS
> Signed-off-by: aknautiy
> ---
> tests/kms_frontbuffer_tracking.c | 166
> +++
> 1 file changed, 151 insertions(+), 15 deletions(-)
>
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index a068c8a..b06d304 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -34,7 +34,7 @@
>
>
> IGT_TEST_DESCRIPTION("Test the Kernel's frontbuffer tracking
> mechanism and "
> - "its related features: FBC and PSR");
> + "its related features: FBC, DRRS and PSR");
>
> /*
> * One of the aspects of this test is that, for every subtest, we
> try different
> @@ -105,8 +105,9 @@ struct test_mode {
> FEATURE_NONE = 0,
> FEATURE_FBC = 1,
> FEATURE_PSR = 2,
> - FEATURE_COUNT = 4,
> - FEATURE_DEFAULT = 4,
> + FEATURE_DRRS = 4,
> + FEATURE_COUNT = 6,
> + FEATURE_DEFAULT = 6,
> } feature;
>
> /* Possible pixel formats. We just use FORMAT_DEFAULT for
> most tests and
> @@ -156,6 +157,7 @@ struct rect {
> struct {
> int fd;
> int debugfs;
> + int drrs_debugfs_fd;
> drmModeResPtr res;
> drmModeConnectorPtr connectors[MAX_CONNECTORS];
> drmModeEncoderPtr encoders[MAX_ENCODERS];
> @@ -178,10 +180,8 @@ struct {
>
> struct {
> bool can_test;
> -} psr = {
> - .can_test = false,
> -};
> -
> +} psr = { .can_test = false,},
> +drrs = { .can_test = false,};
>
> #define SINK_CRC_SIZE 12
> typedef struct {
> @@ -775,8 +775,8 @@ static bool set_mode_for_params(struct
> modeset_params *params)
> int rc;
>
> rc = drmModeSetCrtc(drm.fd, params->crtc_id, params->fb.fb-
> >fb_id,
> - params->fb.x, params->fb.y,
> - ¶ms->connector_id, 1, params->mode);
> + params->fb.x, params->fb.y,
> + ¶ms->connector_id, 1, params-
> >mode);
> return (rc == 0);
> }
>
> @@ -822,6 +822,63 @@ static void psr_print_status(void)
> igt_info("PSR status:\n%s\n", buf);
> }
>
> +void drrs_set(unsigned int val)
> +{
> + char buf[16];
> +
> +
Re: [Intel-gfx] [PATCH] drm/i915: Fix indentation for intel_ddi_clk_select
Em Ter, 2017-12-19 às 11:26 +, Chris Wilson escreveu:
> drivers/gpu/drm/i915/intel_ddi.c:2098 intel_ddi_clk_select() warn:
> inconsistent indenting
>
> References: 8edcda1266f9 ("drm/i915: Protect DDI port to DPLL map
> from theoretical race.")
> Signed-off-by: Chris Wilson
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index f624ba8e23be..f51645a08dca 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2095,7 +2095,7 @@ static void intel_ddi_clk_select(struct
> intel_encoder *encoder,
> if (WARN_ON(!pll))
> return;
>
> - mutex_lock(&dev_priv->dpll_lock);
> + mutex_lock(&dev_priv->dpll_lock);
>
> if (IS_CANNONLAKE(dev_priv)) {
> /* Configure DPCLKA_CFGCR0 to map the DPLL to the
> DDI. */
> @@ -2117,7 +2117,7 @@ static void intel_ddi_clk_select(struct
> intel_encoder *encoder,
> val = I915_READ(DPLL_CTRL2);
>
> val &= ~(DPLL_CTRL2_DDI_CLK_OFF(port) |
> - DPLL_CTRL2_DDI_CLK_SEL_MASK(port));
> + DPLL_CTRL2_DDI_CLK_SEL_MASK(port));
> val |= (DPLL_CTRL2_DDI_CLK_SEL(pll->id, port) |
> DPLL_CTRL2_DDI_SEL_OVERRIDE(port));
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Show FBC worker status in debugfs
Em Qua, 2017-12-20 às 20:58 +, Chris Wilson escreveu:
> Include the pending update from the FBC worker in i915_fbc_status.
>
> Signed-off-by: Chris Wilson
> Cc: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index c4780f085428..931037a458be 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1581,18 +1581,23 @@ static int i915_frontbuffer_tracking(struct
> seq_file *m, void *unused)
> static int i915_fbc_status(struct seq_file *m, void *unused)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m-
> >private);
> + struct intel_fbc *fbc = &dev_priv->fbc;
>
> if (!HAS_FBC(dev_priv))
> return -ENODEV;
>
> intel_runtime_pm_get(dev_priv);
> - mutex_lock(&dev_priv->fbc.lock);
> + mutex_lock(&fbc->lock);
>
> if (intel_fbc_is_active(dev_priv))
> seq_puts(m, "FBC enabled\n");
> else
> - seq_printf(m, "FBC disabled: %s\n",
> - dev_priv->fbc.no_fbc_reason);
> + seq_printf(m, "FBC disabled: %s\n", fbc-
> >no_fbc_reason);
> +
> + if (fbc->work.scheduled)
> + seq_printf(m, "FBC worker scheduled on vblank %d,
vblank %u since this is u32?
Reviewed-by: Paulo Zanoni
> now %llu\n",
> + fbc->work.scheduled_vblank,
> + drm_crtc_vblank_count(&fbc->crtc->base));
>
> if (intel_fbc_is_active(dev_priv)) {
> u32 mask;
> @@ -1612,7 +1617,7 @@ static int i915_fbc_status(struct seq_file *m,
> void *unused)
> seq_printf(m, "Compressing: %s\n", yesno(mask));
> }
>
> - mutex_unlock(&dev_priv->fbc.lock);
> + mutex_unlock(&fbc->lock);
> intel_runtime_pm_put(dev_priv);
>
> return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Enable edp psr error interrupts on hsw
Em Qui, 2018-04-05 às 15:00 -0700, Dhinakaran Pandiyan escreveu:
> From: Daniel Vetter
>
> The definitions for the error register should be valid on bdw/skl
> too,
> but there we haven't even enabled DE_MISC handling yet.
>
> Somewhat confusing the the moved register offset on bdw is only for
> the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
> on bdw.
>
> v2: Fixes from Ville.
>
> v3: From DK
> * Rebased on drm-tip
> * Removed BDW IIR bit definition, looks like an unintentional change
> that
> should be in the following patch.
>
> v4: From DK
> * Don't mask REG_WRITE.
>
> References: bspec/11974 [SRD Interrupt Bit Definition DevHSW]
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Daniel Vetter
> Signed-off-by: Daniel Vetter
> Signed-off-by: Dhinakaran Pandiyan
> Reviewed-by: Jose Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_irq.c | 34
> ++
> drivers/gpu/drm/i915/i915_reg.h | 8
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 27aee25429b7..c2d3f30778ee 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2391,6 +2391,26 @@ static void ilk_display_irq_handler(struct
> drm_i915_private *dev_priv,
> ironlake_rps_change_irq_handler(dev_priv);
> }
>
> +static void hsw_edp_psr_irq_handler(struct drm_i915_private
> *dev_priv)
> +{
> + u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> +
> + if (edp_psr_iir & EDP_PSR_ERROR)
> + DRM_DEBUG_KMS("PSR error\n");
> +
> + if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> + DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> + I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
Why are we masking it here? During these 2 vblanks it's possible that
something will happen (e.g., frontbuffer writing, cursor moving, page
flipping). Are we guaranteed to get a POST_EXIT interrupt even if we
give up entering PSR before it is actually entered?
> + }
> +
> + if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> + DRM_DEBUG_KMS("PSR exit completed\n");
> + I915_WRITE(EDP_PSR_IMR, 0);
> + }
> +
> + I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> +}
> +
> static void ivb_display_irq_handler(struct drm_i915_private
> *dev_priv,
> u32 de_iir)
> {
> @@ -2403,6 +2423,9 @@ static void ivb_display_irq_handler(struct
> drm_i915_private *dev_priv,
> if (de_iir & DE_ERR_INT_IVB)
> ivb_err_int_handler(dev_priv);
>
> + if (de_iir & DE_EDP_PSR_INT_HSW)
> + hsw_edp_psr_irq_handler(dev_priv);
> +
> if (de_iir & DE_AUX_CHANNEL_A_IVB)
> dp_aux_irq_handler(dev_priv);
>
> @@ -3260,6 +3283,11 @@ static void ironlake_irq_reset(struct
> drm_device *dev)
> if (IS_GEN7(dev_priv))
> I915_WRITE(GEN7_ERR_INT, 0x);
>
> + if (IS_HASWELL(dev_priv)) {
> + I915_WRITE(EDP_PSR_IMR, 0x);
> + I915_WRITE(EDP_PSR_IIR, 0x);
> + }
We need another IIR write we do for the other platforms. This is not
cargo cult (as mentioned in previous review emails), this is required
since our hardware is able to store more than one IIR interrupt. Please
do it like we do for the other interrupts.
Do git-blame in the relevant lines and read the commit messages for
more information on why stuff is the way it is. If you still think this
is unnecessary, feel free to write a patch removing the unnecessary
stuff for every interrupt instead of of making just one register be
not-cargo-culted.
> +
> gen5_gt_irq_reset(dev_priv);
>
> ibx_irq_reset(dev_priv);
> @@ -3671,6 +3699,12 @@ static int ironlake_irq_postinstall(struct
> drm_device *dev)
> DE_DP_A_HOTPLUG);
> }
>
> + if (IS_HASWELL(dev_priv)) {
> + gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
> + I915_WRITE(EDP_PSR_IMR, 0);
> + display_mask |= DE_EDP_PSR_INT_HSW;
> + }
> +
> dev_priv->irq_mask = ~display_mask;
>
> ibx_irq_pre_postinstall(dev);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 176dca6554f4..f5783d6db614 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4011,6 +4011,13 @@ enum {
> #define EDP_PSR_TP1_TIME_0us (3<<4)
> #define EDP_PSR_IDLE_FRAME_SHIFT 0
>
> +/* Bspec claims those aren't shifted but stay at 0x64800 */
> +#define EDP_PSR_IMR _MMIO(0x64834)
> +#define EDP_PSR_IIR _MMIO(0x64838)
> +#define EDP_PSR_ERROR (1<<2)
> +#define EDP_PSR_POST_EXIT (1<<1)
> +#define EDP_PSR_PRE_ENTRY (1<<0)
> +
I know you'll remove these definitions in the next patch, but please
make sure you add the definiti
Re: [Intel-gfx] [PATCH 3/8] drm/i915/icl: add basic support for the ICL clocks
Em Seg, 2018-04-09 às 16:23 -0700, James Ausmus escreveu: > On Wed, Mar 28, 2018 at 02:57:58PM -0700, Paulo Zanoni wrote: > > This commit introduces the definitions for the ICL clocks and adds > > the > > basic functions to the shared DPLL framework. It adds code for the > > Enable and Disable sequences for some PLLs, but it does not have > > the > > code to compute the actual PLL values, which are marked as TODO > > comments and should be introduced as separate commits. > > > > Special thanks to James Ausmus for investigating and fixing a bug > > with > > the placement of icl_unmap_plls_to_ports() function. > > > > v2: > > - Rebase around dpll_lock changes. > > v3: > > - The spec now says what the timeouts should be. > > - Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't > > freeze > >the machine. > > - Checkpatch found a white space problem. > > - Small adjustments before upstreaming. > > v4: > > - Move the ICL checks out of the *map_plls_to_ports() functions > > (James) > > - Add extra encoder check (James) > > - Call icl_unmap_plls_to_ports() later (James) > > v5: > > - Rebase after the pll struct changes. > > > > Cc: James Ausmus > > Signed-off-by: Paulo Zanoni > > --- > > drivers/gpu/drm/i915/i915_debugfs.c | 22 +++ > > drivers/gpu/drm/i915/intel_ddi.c | 98 ++- > > drivers/gpu/drm/i915/intel_display.c | 16 ++ > > drivers/gpu/drm/i915/intel_dpll_mgr.c | 312 > > +- > > drivers/gpu/drm/i915/intel_dpll_mgr.h | 41 + > > drivers/gpu/drm/i915/intel_drv.h | 6 + > > 6 files changed, 490 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > > b/drivers/gpu/drm/i915/i915_debugfs.c > > index ff90577da450..43a805c39b0a 100644 > > --- a/drivers/gpu/drm/i915/i915_debugfs.c > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > > @@ -3296,6 +3296,28 @@ static int i915_shared_dplls_info(struct > > seq_file *m, void *unused) > > seq_printf(m, " fp0: 0x%08x\n", pll- > > >state.hw_state.fp0); > > seq_printf(m, " fp1: 0x%08x\n", pll- > > >state.hw_state.fp1); > > seq_printf(m, " wrpll: 0x%08x\n", pll- > > >state.hw_state.wrpll); > > + seq_printf(m, " cfgcr0: 0x%08x\n", pll- > > >state.hw_state.cfgcr0); > > + seq_printf(m, " cfgcr1: 0x%08x\n", pll- > > >state.hw_state.cfgcr1); > > + seq_printf(m, " mg_refclkin_ctl:0x%08x\n", > > + pll->state.hw_state.mg_refclkin_ctl); > > + seq_printf(m, " mg_clktop2_coreclkctl1: 0x%08x\n", > > + pll- > > >state.hw_state.mg_clktop2_coreclkctl1); > > + seq_printf(m, " mg_clktop2_hsclkctl:0x%08x\n", > > + pll- > > >state.hw_state.mg_clktop2_hsclkctl); > > + seq_printf(m, " mg_pll_div0: 0x%08x\n", > > + pll->state.hw_state.mg_pll_div0); > > + seq_printf(m, " mg_pll_div1: 0x%08x\n", > > + pll->state.hw_state.mg_pll_div1); > > + seq_printf(m, " mg_pll_lf:0x%08x\n", > > + pll->state.hw_state.mg_pll_lf); > > + seq_printf(m, " mg_pll_frac_lock: 0x%08x\n", > > + pll->state.hw_state.mg_pll_frac_lock); > > + seq_printf(m, " mg_pll_ssc: 0x%08x\n", > > + pll->state.hw_state.mg_pll_ssc); > > + seq_printf(m, " mg_pll_bias: 0x%08x\n", > > + pll->state.hw_state.mg_pll_bias); > > + seq_printf(m, " mg_pll_tdc_coldst_bias: 0x%08x\n", > > + pll- > > >state.hw_state.mg_pll_tdc_coldst_bias); > > } > > drm_modeset_unlock_all(dev); > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > > b/drivers/gpu/drm/i915/intel_ddi.c > > index a6672a9abd85..10223ffcceab 100644 > > --- a/drivers/gpu/drm/i915/intel_ddi.c > > +++ b/drivers/gpu/drm/i915/intel_ddi.c > > @@ -1013,6 +1013,25 @@ static uint32_t hsw_pll_to_ddi_pll_sel(const > > struct intel_shared_dpll *pll) > > } > > } > > > > +static uint32_t icl_pll_to_ddi_pll_sel(struct intel_encoder > > *encoder, > > + const struct >
Re: [Intel-gfx] [PATCH 08/17] drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI
Em Qui, 2018-04-05 às 17:20 -0700, Rodrigo Vivi escreveu:
> On Thu, Feb 22, 2018 at 12:55:10AM -0300, Paulo Zanoni wrote:
> > From: Manasi Navare
> >
> > This is an important part of the DDI initalization as well as
> > for changing the voltage during DisplayPort link training.
> >
> > The Voltage swing seqeuence is similar to Cannonlake.
> > However it has different register definitions and hence
> > it makes sense to create a separate vswing sequence and
> > program functions for ICL to leave room for more changes
> > in case the Bspec changes later and deviates from CNL sequence.
> >
> > v2:
> > Use ~TAP3_DISABLE for enbaling that bit (Jani Nikula)
> >
> > v3:
> > * Use dw4_scaling column for PORT_TX_DW4 values (Rodrigo)
> >
> > v4:
> > * Call it combo_vswing, use switch statement (Paulo)
> >
> > v5 (from Paulo):
> > * Fix a typo.
> > * s/rate < 60/rate <= 60/.
> > * Don't remove blank lines that should be there.
> >
> > v6:
> > * Rebased by Rodrigo on top of Cannonlake changes
> > where non vswing sequences are not aligned with iboost
> > anymore.
> >
> > v7: Another rebase after an upstream rework.
> >
> > v8 (from Paulo):
> > * Adjust the code to the upstream output type changes.
> > * Squash the patch that moved some functions up.
> > * Merge both get_combo_buf_trans functions in order to simplify the
> > code.
> > * Change the changelog format.
> >
> > Cc: Jani Nikula
> > Reviewed-by: Paulo Zanoni (v5)
> > Signed-off-by: Manasi Navare
> > Signed-off-by: Rodrigo Vivi
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 189
> > ++-
> > 1 file changed, 186 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 0a4683991ec2..c38873cb98ca 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -849,6 +849,45 @@ cnl_get_buf_trans_edp(struct drm_i915_private
> > *dev_priv, int *n_entries)
> > }
> > }
> >
> > +static const struct icl_combo_phy_ddi_buf_trans *
> > +icl_get_combo_buf_trans(struct drm_i915_private *dev_priv, enum
> > port port,
> > + int type, int *n_entries)
> > +{
> > + u32 voltage = I915_READ(ICL_PORT_COMP_DW3(port)) &
> > VOLTAGE_INFO_MASK;
> > +
> > + if (type == INTEL_OUTPUT_EDP && dev_priv-
> > >vbt.edp.low_vswing) {
> > + switch (voltage) {
> > + case VOLTAGE_INFO_0_85V:
> > + *n_entries =
> > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_85V);
> > + return
> > icl_combo_phy_ddi_translations_edp_0_85V;
> > + case VOLTAGE_INFO_0_95V:
> > + *n_entries =
> > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_95V);
> > + return
> > icl_combo_phy_ddi_translations_edp_0_95V;
> > + case VOLTAGE_INFO_1_05V:
> > + *n_entries =
> > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_1_05V);
> > + return
> > icl_combo_phy_ddi_translations_edp_1_05V;
> > + default:
> > + MISSING_CASE(voltage);
> > + return NULL;
> > + }
> > + } else {
>
> DP ends up here on HDMI?
> This is strange...
DP ends on the "dp_hdmi" part, while edp ends on the "edp" part. What
is strange about that?
>
> Also, for clarity, why not to split this into separated functions
> like all other platforms?
So we don't end up reading PORT_COMP_DW3 multiple times (like we do for
CNL), and as a bonus the code looks better IMHO.
>
> > + switch (voltage) {
> > + case VOLTAGE_INFO_0_85V:
> > + *n_entries =
> > ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_0_85V);
> > + return
> > icl_combo_phy_ddi_translations_dp_hdmi_0_85V;
> > + case VOLTAGE_INFO_0_95V:
> > + *n_entries =
> > ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_0_95V);
> > + return
> > icl_combo_phy_ddi_translations_dp_hdmi_0_95V;
> > + case VOLTAGE_INFO_1_05V:
> > + *n_entries =
> > ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_1_05V);
> > + return
> > icl_combo_phy_d
Re: [Intel-gfx] [PATCH 08/17] drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI
Em Qua, 2018-04-25 às 11:01 -0700, Rodrigo Vivi escreveu:
> On Tue, Apr 24, 2018 at 05:34:14PM -0700, Paulo Zanoni wrote:
> > Em Qui, 2018-04-05 às 17:20 -0700, Rodrigo Vivi escreveu:
> > > On Thu, Feb 22, 2018 at 12:55:10AM -0300, Paulo Zanoni wrote:
> > > > From: Manasi Navare
> > > >
> > > > This is an important part of the DDI initalization as well as
> > > > for changing the voltage during DisplayPort link training.
> > > >
> > > > The Voltage swing seqeuence is similar to Cannonlake.
> > > > However it has different register definitions and hence
> > > > it makes sense to create a separate vswing sequence and
> > > > program functions for ICL to leave room for more changes
> > > > in case the Bspec changes later and deviates from CNL sequence.
> > > >
> > > > v2:
> > > > Use ~TAP3_DISABLE for enbaling that bit (Jani Nikula)
> > > >
> > > > v3:
> > > > * Use dw4_scaling column for PORT_TX_DW4 values (Rodrigo)
> > > >
> > > > v4:
> > > > * Call it combo_vswing, use switch statement (Paulo)
> > > >
> > > > v5 (from Paulo):
> > > > * Fix a typo.
> > > > * s/rate < 60/rate <= 60/.
> > > > * Don't remove blank lines that should be there.
> > > >
> > > > v6:
> > > > * Rebased by Rodrigo on top of Cannonlake changes
> > > > where non vswing sequences are not aligned with iboost
> > > > anymore.
> > > >
> > > > v7: Another rebase after an upstream rework.
> > > >
> > > > v8 (from Paulo):
> > > > * Adjust the code to the upstream output type changes.
> > > > * Squash the patch that moved some functions up.
> > > > * Merge both get_combo_buf_trans functions in order to simplify
> > > > the
> > > > code.
> > > > * Change the changelog format.
> > > >
> > > > Cc: Jani Nikula
> > > > Reviewed-by: Paulo Zanoni (v5)
> > > > Signed-off-by: Manasi Navare
> > > > Signed-off-by: Rodrigo Vivi
> > > > Signed-off-by: Paulo Zanoni
> > > > ---
> > > > drivers/gpu/drm/i915/intel_ddi.c | 189
> > > > ++-
> > > > 1 file changed, 186 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index 0a4683991ec2..c38873cb98ca 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -849,6 +849,45 @@ cnl_get_buf_trans_edp(struct
> > > > drm_i915_private
> > > > *dev_priv, int *n_entries)
> > > > }
> > > > }
> > > >
> > > > +static const struct icl_combo_phy_ddi_buf_trans *
> > > > +icl_get_combo_buf_trans(struct drm_i915_private *dev_priv,
> > > > enum
> > > > port port,
> > > > + int type, int *n_entries)
> > > > +{
> > > > + u32 voltage = I915_READ(ICL_PORT_COMP_DW3(port)) &
> > > > VOLTAGE_INFO_MASK;
> > > > +
> > > > + if (type == INTEL_OUTPUT_EDP && dev_priv-
> > > > > vbt.edp.low_vswing) {
> > > >
> > > > + switch (voltage) {
> > > > + case VOLTAGE_INFO_0_85V:
> > > > + *n_entries =
> > > > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_85V);
> > > > + return
> > > > icl_combo_phy_ddi_translations_edp_0_85V;
> > > > + case VOLTAGE_INFO_0_95V:
> > > > + *n_entries =
> > > > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_95V);
> > > > + return
> > > > icl_combo_phy_ddi_translations_edp_0_95V;
> > > > + case VOLTAGE_INFO_1_05V:
> > > > + *n_entries =
> > > > ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_1_05V);
> > > > + return
> > > > icl_combo_phy_ddi_translations_edp_1_05V;
> > > > + default:
> > > > + MISSING_CASE(voltage);
> > > > + return NULL;
> > > > + }
> >
[Intel-gfx] [PATCH libdrm] intel: add support for ICL 11
Add the PCI IDs and the basic code to enable ICL. This is the current
PCI ID list in our documentation.
Kernel commit: d55cb4fa2cf0 ("drm/i915/icl: Add the ICL PCI IDs")
v2: Michel provided a fix to IS_9XX that was broken by rebase bot.
v3: Fix double definition of PCI IDs, update IDs according to bspec
and keep them in the same order and rebase (Lucas)
Cc: Michel Thierry
Signed-off-by: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
Signed-off-by: Lucas De Marchi
---
intel/intel_bufmgr_gem.c | 2 ++
intel/intel_chipset.h| 27 ++-
intel/intel_decode.c | 4 +++-
3 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 5c47a46f..8c3a4b20 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3660,6 +3660,8 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
bufmgr_gem->gen = 9;
else if (IS_GEN10(bufmgr_gem->pci_device))
bufmgr_gem->gen = 10;
+ else if (IS_GEN11(bufmgr_gem->pci_device))
+ bufmgr_gem->gen = 11;
else {
free(bufmgr_gem);
bufmgr_gem = NULL;
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index ba2e3ac1..32b2c48f 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -257,6 +257,16 @@
#define PCI_CHIP_CANNONLAKE_12 0x5A44
#define PCI_CHIP_CANNONLAKE_13 0x5A4C
+#define PCI_CHIP_ICELAKE_11_0 0x8A50
+#define PCI_CHIP_ICELAKE_11_1 0x8A51
+#define PCI_CHIP_ICELAKE_11_2 0x8A5C
+#define PCI_CHIP_ICELAKE_11_3 0x8A5D
+#define PCI_CHIP_ICELAKE_11_4 0x8A52
+#define PCI_CHIP_ICELAKE_11_5 0x8A5A
+#define PCI_CHIP_ICELAKE_11_6 0x8A5B
+#define PCI_CHIP_ICELAKE_11_7 0x8A71
+#define PCI_CHIP_ICELAKE_11_8 0x8A70
+
#define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
(devid) == PCI_CHIP_I915_GM || \
(devid) == PCI_CHIP_I945_GM || \
@@ -538,6 +548,20 @@
#define IS_GEN10(devid)(IS_CANNONLAKE(devid))
+#define IS_ICELAKE_11(devid) ((devid) == PCI_CHIP_ICELAKE_11_0 || \
+(devid) == PCI_CHIP_ICELAKE_11_1 || \
+(devid) == PCI_CHIP_ICELAKE_11_2 || \
+(devid) == PCI_CHIP_ICELAKE_11_3 || \
+(devid) == PCI_CHIP_ICELAKE_11_4 || \
+(devid) == PCI_CHIP_ICELAKE_11_5 || \
+(devid) == PCI_CHIP_ICELAKE_11_6 || \
+(devid) == PCI_CHIP_ICELAKE_11_7 || \
+(devid) == PCI_CHIP_ICELAKE_11_8)
+
+#define IS_ICELAKE(devid) (IS_ICELAKE_11(devid))
+
+#define IS_GEN11(devid)(IS_ICELAKE_11(devid))
+
#define IS_9XX(dev)(IS_GEN3(dev) || \
IS_GEN4(dev) || \
IS_GEN5(dev) || \
@@ -545,6 +569,7 @@
IS_GEN7(dev) || \
IS_GEN8(dev) || \
IS_GEN9(dev) || \
-IS_GEN10(dev))
+IS_GEN10(dev) || \
+IS_GEN11(dev))
#endif /* _INTEL_CHIPSET_H */
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index bc7b04b8..b24861b1 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -3823,7 +3823,9 @@ drm_intel_decode_context_alloc(uint32_t devid)
ctx->devid = devid;
ctx->out = stdout;
- if (IS_GEN10(devid))
+ if (IS_GEN11(devid))
+ ctx->gen = 11;
+ else if (IS_GEN10(devid))
ctx->gen = 10;
else if (IS_GEN9(devid))
ctx->gen = 9;
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: configure the transcoder clocks before touching pipeconf on HSW+
For all platforms that run haswell_crtc_enable, our spec tells us to
configure the transcoder clocks before it tells us to set pipeconf and
the other pipe/transcoder/plane registers.
For some reason we've been able to get away with doing what we were
doing until now, but starting from Icelake, we get machine hangs if we
try to touch the pipe/transcoder registers without having the clocks
configured.
So this patch changes all the relevant platforms to call
intel_ddi_enable_pipe_clock at the point we're supposed to, according
to the spec.
It seems there is a way to work around this problem on ICL with some
chicken bit, but I still couldn't find which one it is, and it's
better if we just do the right thing here.
Cc: Arthur J Runyan
Cc: James Ausmus
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
Luckily our CI system should be in a spot where it is able to tell us
whether this patch is good with high confidence. I haven't tested it
on every affected platform.
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 48576ea2d36c..c93aed2ec16d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5578,8 +5578,11 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
&intel_crtc->config->fdi_m_n, NULL);
}
- if (!transcoder_is_dsi(cpu_transcoder))
+ if (!transcoder_is_dsi(cpu_transcoder)) {
+ intel_ddi_enable_pipe_clock(pipe_config);
+
haswell_set_pipeconf(crtc);
+ }
haswell_set_pipemisc(crtc);
@@ -5589,9 +5592,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_encoders_pre_enable(crtc, pipe_config, old_state);
- if (!transcoder_is_dsi(cpu_transcoder))
- intel_ddi_enable_pipe_clock(pipe_config);
-
/* Display WA #1180: WaDisableScalarClockGating: glk, cnl */
psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
intel_crtc->config->pch_pfit.enabled;
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915/icl: add basic support for the ICL clocks
This commit introduces the definitions for the ICL clocks and adds the
basic functions to the shared DPLL framework. It adds code for the
Enable and Disable sequences for some PLLs, but it does not have the
code to compute the actual PLL values, which are marked as TODO
comments and should be introduced as separate commits.
Special thanks to James Ausmus for investigating and fixing a bug with
the placement of icl_unmap_plls_to_ports() function.
v2:
- Rebase around dpll_lock changes.
v3:
- The spec now says what the timeouts should be.
- Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze
the machine.
- Checkpatch found a white space problem.
- Small adjustments before upstreaming.
v4:
- Move the ICL checks out of the *map_plls_to_ports() functions
(James)
- Add extra encoder check (James)
- Call icl_unmap_plls_to_ports() later (James)
v5:
- Rebase after the pll struct changes.
v6:
- Properly make the unmap function based on encoders_post_disable()
with regarding to checks and iterators.
- Address checkpatch comment on "min = max = x()".
Cc: James Ausmus
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 22 +++
drivers/gpu/drm/i915/intel_ddi.c | 98 ++-
drivers/gpu/drm/i915/intel_display.c | 16 ++
drivers/gpu/drm/i915/intel_dpll_mgr.c | 313 +-
drivers/gpu/drm/i915/intel_dpll_mgr.h | 41 +
drivers/gpu/drm/i915/intel_drv.h | 6 +
6 files changed, 491 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index cb1a804bf72e..ba8927cb1dcc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3365,6 +3365,28 @@ static int i915_shared_dplls_info(struct seq_file *m,
void *unused)
seq_printf(m, " fp0: 0x%08x\n", pll->state.hw_state.fp0);
seq_printf(m, " fp1: 0x%08x\n", pll->state.hw_state.fp1);
seq_printf(m, " wrpll: 0x%08x\n", pll->state.hw_state.wrpll);
+ seq_printf(m, " cfgcr0: 0x%08x\n", pll->state.hw_state.cfgcr0);
+ seq_printf(m, " cfgcr1: 0x%08x\n", pll->state.hw_state.cfgcr1);
+ seq_printf(m, " mg_refclkin_ctl:0x%08x\n",
+ pll->state.hw_state.mg_refclkin_ctl);
+ seq_printf(m, " mg_clktop2_coreclkctl1: 0x%08x\n",
+ pll->state.hw_state.mg_clktop2_coreclkctl1);
+ seq_printf(m, " mg_clktop2_hsclkctl:0x%08x\n",
+ pll->state.hw_state.mg_clktop2_hsclkctl);
+ seq_printf(m, " mg_pll_div0: 0x%08x\n",
+ pll->state.hw_state.mg_pll_div0);
+ seq_printf(m, " mg_pll_div1: 0x%08x\n",
+ pll->state.hw_state.mg_pll_div1);
+ seq_printf(m, " mg_pll_lf:0x%08x\n",
+ pll->state.hw_state.mg_pll_lf);
+ seq_printf(m, " mg_pll_frac_lock: 0x%08x\n",
+ pll->state.hw_state.mg_pll_frac_lock);
+ seq_printf(m, " mg_pll_ssc: 0x%08x\n",
+ pll->state.hw_state.mg_pll_ssc);
+ seq_printf(m, " mg_pll_bias: 0x%08x\n",
+ pll->state.hw_state.mg_pll_bias);
+ seq_printf(m, " mg_pll_tdc_coldst_bias: 0x%08x\n",
+ pll->state.hw_state.mg_pll_tdc_coldst_bias);
}
drm_modeset_unlock_all(dev);
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 92cb26b18a9b..178a7b0d0149 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1013,6 +1013,25 @@ static uint32_t hsw_pll_to_ddi_pll_sel(const struct
intel_shared_dpll *pll)
}
}
+static uint32_t icl_pll_to_ddi_pll_sel(struct intel_encoder *encoder,
+ const struct intel_shared_dpll *pll)
+{
+ const enum intel_dpll_id id = pll->info->id;
+
+ switch (id) {
+ default:
+ MISSING_CASE(id);
+ case DPLL_ID_ICL_DPLL0:
+ case DPLL_ID_ICL_DPLL1:
+ return DDI_CLK_SEL_NONE;
+ case DPLL_ID_ICL_MGPLL1:
+ case DPLL_ID_ICL_MGPLL2:
+ case DPLL_ID_ICL_MGPLL3:
+ case DPLL_ID_ICL_MGPLL4:
+ return DDI_CLK_SEL_MG;
+ }
+}
+
/* Starting with Haswell, different DDI ports can work in FDI mode for
* connection to the PCH-located connectors. For this, it is necessary to train
* both the DDI port and PCH receiver for the desired DDI buffer settings.
@@ -2234,6 +2253,69 @@ uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
return DDI_BUF_TRANS_SELECT(level);
}
+v
Re: [Intel-gfx] [PATCH libdrm] intel: add support for ICL 11
Em Qua, 2018-04-25 às 17:29 -0700, Michel Thierry escreveu:
> On 04/25/2018 05:09 PM, Paulo Zanoni wrote:
> > Add the PCI IDs and the basic code to enable ICL. This is the
> > current
> > PCI ID list in our documentation.
> >
> > Kernel commit: d55cb4fa2cf0 ("drm/i915/icl: Add the ICL PCI IDs")
> >
> > v2: Michel provided a fix to IS_9XX that was broken by rebase bot.
> > v3: Fix double definition of PCI IDs, update IDs according to bspec
> > and keep them in the same order and rebase (Lucas)
> >
> > Cc: Michel Thierry
> > Signed-off-by: Paulo Zanoni
> > Signed-off-by: Rodrigo Vivi
> > Signed-off-by: Lucas De Marchi
> > ---
> > intel/intel_bufmgr_gem.c | 2 ++
> > intel/intel_chipset.h| 27 ++-
> > intel/intel_decode.c | 4 +++-
> > 3 files changed, 31 insertions(+), 2 deletions(-)
> >
> > diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> > index 5c47a46f..8c3a4b20 100644
> > --- a/intel/intel_bufmgr_gem.c
> > +++ b/intel/intel_bufmgr_gem.c
> > @@ -3660,6 +3660,8 @@ drm_intel_bufmgr_gem_init(int fd, int
> > batch_size)
> > bufmgr_gem->gen = 9;
> > else if (IS_GEN10(bufmgr_gem->pci_device))
> > bufmgr_gem->gen = 10;
> > + else if (IS_GEN11(bufmgr_gem->pci_device))
> > + bufmgr_gem->gen = 11;
> > else {
> > free(bufmgr_gem);
> > bufmgr_gem = NULL;
> > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > index ba2e3ac1..32b2c48f 100644
> > --- a/intel/intel_chipset.h
> > +++ b/intel/intel_chipset.h
> > @@ -257,6 +257,16 @@
> > #define PCI_CHIP_CANNONLAKE_120x5A44
> > #define PCI_CHIP_CANNONLAKE_130x5A4C
> >
> > +#define PCI_CHIP_ICELAKE_11_0 0x8A50
> > +#define PCI_CHIP_ICELAKE_11_1 0x8A51
> > +#define PCI_CHIP_ICELAKE_11_2 0x8A5C
> > +#define PCI_CHIP_ICELAKE_11_3 0x8A5D
> > +#define PCI_CHIP_ICELAKE_11_4 0x8A52
> > +#define PCI_CHIP_ICELAKE_11_5 0x8A5A
> > +#define PCI_CHIP_ICELAKE_11_6 0x8A5B
> > +#define PCI_CHIP_ICELAKE_11_7 0x8A71
> > +#define PCI_CHIP_ICELAKE_11_8 0x8A70
> > +
>
> matches what we have in the kernel's i915_pciids.h
>
> > #define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
> > (devid) == PCI_CHIP_I915_GM || \
> > (devid) == PCI_CHIP_I945_GM || \
> > @@ -538,6 +548,20 @@
> >
> > #define IS_GEN10(devid) (IS_CANNONLAKE(devid))
> >
> > +#define IS_ICELAKE_11(devid) ((devid) ==
> > PCI_CHIP_ICELAKE_11_0 || \
> > +(devid) == PCI_CHIP_ICELAKE_11_1
> > || \
> > +(devid) == PCI_CHIP_ICELAKE_11_2
> > || \
> > +(devid) == PCI_CHIP_ICELAKE_11_3
> > || \
> > +(devid) == PCI_CHIP_ICELAKE_11_4
> > || \
> > +(devid) == PCI_CHIP_ICELAKE_11_5
> > || \
> > +(devid) == PCI_CHIP_ICELAKE_11_6
> > || \
> > +(devid) == PCI_CHIP_ICELAKE_11_7
> > || \
> > +(devid) == PCI_CHIP_ICELAKE_11_8)
> > +
> > +#define IS_ICELAKE(devid) (IS_ICELAKE_11(devid))
> > +
> > +#define IS_GEN11(devid)(IS_ICELAKE_11(devid))
> > +
> > #define IS_9XX(dev) (IS_GEN3(dev) || \
> > IS_GEN4(dev) || \
> > IS_GEN5(dev) || \
> > @@ -545,6 +569,7 @@
> > IS_GEN7(dev) || \
> > IS_GEN8(dev) || \
> > IS_GEN9(dev) || \
> > -IS_GEN10(dev))
> > +IS_GEN10(dev) || \
> > +IS_GEN11(dev))
> >
> > #endif /* _INTEL_CHIPSET_H */
> > diff --git a/intel/intel_decode.c b/intel/intel_decode.c
> > index bc7b04b8..b24861b1 100644
> > --- a/intel/intel_decode.c
> > +++ b/intel/intel_decode.c
> > @@ -3823,7 +3823,9 @@ drm_intel_decode_context_alloc(uint32_t
> > devid)
> > ctx->devid = devid;
> > ctx->out = stdout;
> >
> > - if (IS_GEN10(devid))
> > + if (IS_GEN11(devid))
> > + ctx->gen = 11;
> > + else if (IS_GEN10(devid))
> > ctx->gen = 10;
> > else if (IS_GEN9(devid))
> > ctx->gen = 9;
> >
>
> Reviewed-by: Michel Thierry
Patch merged. Thanks everybody involved.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: configure the transcoder clocks before touching pipeconf on HSW+
Em Seg, 2018-04-30 às 21:12 +0300, Ville Syrjälä escreveu:
> On Fri, Apr 27, 2018 at 04:12:08PM -0700, Paulo Zanoni wrote:
> > For all platforms that run haswell_crtc_enable, our spec tells us
> > to
> > configure the transcoder clocks before it tells us to set pipeconf
> > and
> > the other pipe/transcoder/plane registers.
> >
> > For some reason we've been able to get away with doing what we were
> > doing until now, but starting from Icelake, we get machine hangs if
> > we
> > try to touch the pipe/transcoder registers without having the
> > clocks
> > configured.
> >
> > So this patch changes all the relevant platforms to call
> > intel_ddi_enable_pipe_clock at the point we're supposed to,
> > according
> > to the spec.
>
> I don't think this really matches the spec. You're now enabling the
> clock before configuring the port stuff and link training. So AFAICS
> intel_ddi_enable_pipe_clock() seems to be in the correct place, but
> we're just configuring all the pipe/transcoder/etc. stuff way too
> early.
You're right, I missed the link training part, it needs to come before.
But anyway, moving enable_pipe_clock() + link_training ()up is the same
as moving all the pipe/transcoder/etc stuff down, the only difference
being when we set intel_crtc->active. I'll write a second version.
>
> >
> > It seems there is a way to work around this problem on ICL with
> > some
> > chicken bit, but I still couldn't find which one it is, and it's
> > better if we just do the right thing here.
We got the info we wanted and now know how to work around the problem,
but I still think we should go for the solution where we program the
hardware in the order it expects to be programmed.
Or we could do both: program correctly *and* enable the chicken bits.
Thanks,
Paulo
> >
> > Cc: Arthur J Runyan
> > Cc: James Ausmus
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > Luckily our CI system should be in a spot where it is able to tell
> > us
> > whether this patch is good with high confidence. I haven't tested
> > it
> > on every affected platform.
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 48576ea2d36c..c93aed2ec16d 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5578,8 +5578,11 @@ static void haswell_crtc_enable(struct
> > intel_crtc_state *pipe_config,
> > &intel_crtc->config->fdi_m_n,
> > NULL);
> > }
> >
> > - if (!transcoder_is_dsi(cpu_transcoder))
> > + if (!transcoder_is_dsi(cpu_transcoder)) {
> > + intel_ddi_enable_pipe_clock(pipe_config);
> > +
> > haswell_set_pipeconf(crtc);
> > + }
> >
> > haswell_set_pipemisc(crtc);
> >
> > @@ -5589,9 +5592,6 @@ static void haswell_crtc_enable(struct
> > intel_crtc_state *pipe_config,
> >
> > intel_encoders_pre_enable(crtc, pipe_config, old_state);
> >
> > - if (!transcoder_is_dsi(cpu_transcoder))
> > - intel_ddi_enable_pipe_clock(pipe_config);
> > -
> > /* Display WA #1180: WaDisableScalarClockGating: glk, cnl
> > */
> > psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) ||
> > IS_CANNONLAKE(dev_priv)) &&
> > intel_crtc->config->pch_pfit.enabled;
> > --
> > 2.14.3
> >
> > ___
> > 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] [PATCH] drm/i915: enable the pipe/transcoder/planes later on HSW+
For all platforms that run haswell_crtc_enable, our spec tells us to configure the transcoder clocks and do link training before it tells us to set pipeconf and the other pipe/transcoder/plane registers. Starting from Icelake, we get machine hangs if we try to touch the pipe/transcoder registers without having the clocks configured and not having some chicken bits set. So this patch changes haswell_crtc_enable() to issue the calls at the appropriate order mandated by the spec. While setting the appropriate chicken bits would also work here, it's better if we actually program the hardware the way it is intended to be programmed. And the chicken bit also has some theoretical downsides that may or may not affect us. Also, correctly programming the hardware does not prevent us from setting the chicken bits in a later patch in case we decide to. v2: Don't forget link training (Ville). Cc: Arthur J Runyan Cc: James Ausmus Cc: Ville Syrjälä Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_display.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) Again, I didn't test this patch on every affected platform. Let's see what the CI system says about it. diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 1087358f6364..f566c9e56cf6 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5559,6 +5559,11 @@ static void haswell_crtc_enable(struct intel_crtc_state *pipe_config, if (intel_crtc->config->shared_dpll) intel_enable_shared_dpll(intel_crtc); + intel_encoders_pre_enable(crtc, pipe_config, old_state); + + if (!transcoder_is_dsi(cpu_transcoder)) + intel_ddi_enable_pipe_clock(pipe_config); + if (intel_crtc_has_dp_encoder(intel_crtc->config)) intel_dp_set_m_n(intel_crtc, M1_N1); @@ -5587,11 +5592,6 @@ static void haswell_crtc_enable(struct intel_crtc_state *pipe_config, intel_crtc->active = true; - intel_encoders_pre_enable(crtc, pipe_config, old_state); - - if (!transcoder_is_dsi(cpu_transcoder)) - intel_ddi_enable_pipe_clock(pipe_config); - /* Display WA #1180: WaDisableScalarClockGating: glk, cnl */ psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) && intel_crtc->config->pch_pfit.enabled; -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH CI] drm/i915/icl: Add configuring MOCS in new Icelake engines
From: Tomasz Lis
In Icelake, there are more engines on which Memory Object Control States need
to be configured. Besides adding Icelake under Skylake config, the patch makes
sure MOCS register addresses for the new engines are properly defined.
Additional patch might be need later, in case the specification will
propose different MOCS config values for Icelake than in previous gens.
v2: Restricted comments to gen11, updated description, renamed defines.
v3: Used proper engine indexes for gen11.
v4: Ensure patch is Icelake only.
v5: Style fixes (proposed by mwajdeczko)
BSpec: 19405
BSpec: 21140
Cc: Oscar Mateo Lozano
Cc: Daniele Ceraolo Spurio
Reviewed-by: Michel Thierry
Signed-off-by: Tomasz Lis
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_mocs.c | 5 -
2 files changed, 6 insertions(+), 1 deletion(-)
This patch got a r-b tag on 13/02 but got lost in the cracks. Resubmit for CI so
we can possibly merge it.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 197c9660bbc1..085928c9005e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9864,6 +9864,8 @@ enum skl_power_gate {
#define GEN9_MFX1_MOCS(i) _MMIO(0xca00 + (i) * 4) /* Media 1 MOCS
registers */
#define GEN9_VEBOX_MOCS(i) _MMIO(0xcb00 + (i) * 4) /* Video MOCS registers
*/
#define GEN9_BLT_MOCS(i) _MMIO(0xcc00 + (i) * 4) /* Blitter MOCS
registers */
+/* Media decoder 2 MOCS registers */
+#define GEN11_MFX2_MOCS(i) _MMIO(0x1 + (i) * 4)
/* gamt regs */
#define GEN8_L3_LRA_1_GPGPU _MMIO(0x4dd4)
diff --git a/drivers/gpu/drm/i915/intel_mocs.c
b/drivers/gpu/drm/i915/intel_mocs.c
index c0b34b7943b9..9f0bd6a4cb79 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -178,7 +178,8 @@ static bool get_mocs_settings(struct drm_i915_private
*dev_priv,
{
bool result = false;
- if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
+ if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv) ||
+ IS_ICELAKE(dev_priv)) {
table->size = ARRAY_SIZE(skylake_mocs_table);
table->table = skylake_mocs_table;
result = true;
@@ -217,6 +218,8 @@ static i915_reg_t mocs_register(enum intel_engine_id
engine_id, int index)
return GEN9_VEBOX_MOCS(index);
case VCS2:
return GEN9_MFX1_MOCS(index);
+ case VCS3:
+ return GEN11_MFX2_MOCS(index);
default:
MISSING_CASE(engine_id);
return INVALID_MMIO_REG;
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/icl, x86/gpu: implement ICL stolen memory support
ICL changes the registers and addresses to 64 bits.
I also briefly looked at implementing an u64 version of the PCI config
read functions, but I concluded this wouldn't be trivial, so it's not
worth doing it for a single user that can't have any racing problems
while reading the register in two separate operations.
v2:
- Adjust the patch after the i915_stolen_to_dma() changes.
- Remove unused variable (Daniele).
- Update commit message.
v3:
- Fix a missing phys_addr_t->dma_addr_t forgotten in v2 (kbuild bot)
v4:
- Rebase.
v5:
- Fix warnings in arch/x86/kernel/early-quirks.c after rebase.
v6:
- No more TODO list.
- Stay under 80 columns.
- Add debug message to match the other functions.
Issue: VIZ-9250
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: x...@kernel.org
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio # Early
review, needs re-check before merging
Signed-off-by: Paulo Zanoni
---
arch/x86/kernel/early-quirks.c | 18
drivers/gpu/drm/i915/i915_gem_stolen.c | 38 +-
drivers/gpu/drm/i915/i915_reg.h| 1 +
include/drm/i915_drm.h | 4 +++-
4 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index bae0d32e327b..96228bac1c8c 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -340,6 +340,18 @@ static resource_size_t __init gen3_stolen_base(int num,
int slot, int func,
return bsm & INTEL_BSM_MASK;
}
+static resource_size_t __init gen11_stolen_base(int num, int slot, int func,
+resource_size_t stolen_size)
+{
+ u64 bsm;
+
+ bsm = read_pci_config(num, slot, func, INTEL_GEN11_BSM_DW0);
+ bsm &= INTEL_BSM_MASK;
+ bsm |= (u64)read_pci_config(num, slot, func, INTEL_GEN11_BSM_DW1) << 32;
+
+ return (resource_size_t)bsm;
+}
+
static resource_size_t __init i830_stolen_size(int num, int slot, int func)
{
u16 gmch_ctrl;
@@ -500,6 +512,11 @@ static const struct intel_early_ops chv_early_ops
__initconst = {
.stolen_size = chv_stolen_size,
};
+static const struct intel_early_ops gen11_early_ops __initconst = {
+ .stolen_base = gen11_stolen_base,
+ .stolen_size = gen9_stolen_size,
+};
+
static const struct pci_device_id intel_early_ids[] __initconst = {
INTEL_I830_IDS(&i830_early_ops),
INTEL_I845G_IDS(&i845_early_ops),
@@ -531,6 +548,7 @@ static const struct pci_device_id intel_early_ids[]
__initconst = {
INTEL_CFL_IDS(&gen9_early_ops),
INTEL_GLK_IDS(&gen9_early_ops),
INTEL_CNL_IDS(&gen9_early_ops),
+ INTEL_ICL_11_IDS(&gen11_early_ops),
};
struct resource intel_graphics_stolen_res __ro_after_init = DEFINE_RES_MEM(0,
0);
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index ad949cc30928..ede432f6891c 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -343,6 +343,35 @@ static void bdw_get_stolen_reserved(struct
drm_i915_private *dev_priv,
*size = stolen_top - *base;
}
+static void icl_get_stolen_reserved(struct drm_i915_private *dev_priv,
+ resource_size_t *base,
+ resource_size_t *size)
+{
+ uint64_t reg_val = I915_READ64(GEN6_STOLEN_RESERVED);
+
+ DRM_DEBUG_DRIVER("GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
+
+ *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
+
+ switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
+ case GEN8_STOLEN_RESERVED_1M:
+ *size = 1024 * 1024;
+ break;
+ case GEN8_STOLEN_RESERVED_2M:
+ *size = 2 * 1024 * 1024;
+ break;
+ case GEN8_STOLEN_RESERVED_4M:
+ *size = 4 * 1024 * 1024;
+ break;
+ case GEN8_STOLEN_RESERVED_8M:
+ *size = 8 * 1024 * 1024;
+ break;
+ default:
+ *size = 8 * 1024 * 1024;
+ MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
+ }
+}
+
int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
{
resource_size_t reserved_base, stolen_top;
@@ -399,7 +428,9 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
gen7_get_stolen_reserved(dev_priv,
&reserved_base,
&reserved_size);
break;
- default:
+ case 8:
+ case 9:
+ case 10:
if (IS_LP(dev_priv))
chv_get_stolen_reserved(dev_priv,
&reserved_base, &reserved_size);
@@ -407,6 +438,11 @@ int i915_gem_init_stol
Re: [Intel-gfx] [PATCH] drm/i915/icl, x86/gpu: implement ICL stolen memory support
Em Qui, 2018-05-03 às 12:59 +0300, Joonas Lahtinen escreveu:
> Quoting Paulo Zanoni (2018-05-03 03:23:52)
> > ICL changes the registers and addresses to 64 bits.
> >
> > I also briefly looked at implementing an u64 version of the PCI
> > config
> > read functions, but I concluded this wouldn't be trivial, so it's
> > not
> > worth doing it for a single user that can't have any racing
> > problems
> > while reading the register in two separate operations.
> >
> > v2:
> > - Adjust the patch after the i915_stolen_to_dma() changes.
> > - Remove unused variable (Daniele).
> > - Update commit message.
> > v3:
> > - Fix a missing phys_addr_t->dma_addr_t forgotten in v2 (kbuild
> > bot)
> > v4:
> > - Rebase.
> > v5:
> > - Fix warnings in arch/x86/kernel/early-quirks.c after rebase.
> > v6:
> > - No more TODO list.
> > - Stay under 80 columns.
> > - Add debug message to match the other functions.
>
> This will only confuse most readers, so please do scrub the internal
> changelog when sending the first revision on a mailing list.
We've been doing this for years, why did our opinion change today?
>
> > Issue: VIZ-9250
> > Cc: Ingo Molnar
> > Cc: H. Peter Anvin
> > Cc: x...@kernel.org
> > Cc: Daniele Ceraolo Spurio
> > Reviewed-by: Daniele Ceraolo Spurio > m> # Early review, needs re-check before merging
> > Signed-off-by: Paulo Zanoni
> > ---
> > arch/x86/kernel/early-quirks.c | 18
> > drivers/gpu/drm/i915/i915_gem_stolen.c | 38
> > +-
> > drivers/gpu/drm/i915/i915_reg.h| 1 +
> > include/drm/i915_drm.h | 4 +++-
> > 4 files changed, 59 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kernel/early-quirks.c
> > b/arch/x86/kernel/early-quirks.c
> > index bae0d32e327b..96228bac1c8c 100644
> > --- a/arch/x86/kernel/early-quirks.c
> > +++ b/arch/x86/kernel/early-quirks.c
> > @@ -340,6 +340,18 @@ static resource_size_t __init
> > gen3_stolen_base(int num, int slot, int func,
> > return bsm & INTEL_BSM_MASK;
> > }
> >
> > +static resource_size_t __init gen11_stolen_base(int num, int slot,
> > int func,
> > +resource_size_t
> > stolen_size)
> > +{
> > + u64 bsm;
> > +
> > + bsm = read_pci_config(num, slot, func,
> > INTEL_GEN11_BSM_DW0);
> > + bsm &= INTEL_BSM_MASK;
> > + bsm |= (u64)read_pci_config(num, slot, func,
> > INTEL_GEN11_BSM_DW1) << 32;
> > +
> > + return (resource_size_t)bsm;
>
> return bsm; will suffice.
>
> > +}
> > +
> > static resource_size_t __init i830_stolen_size(int num, int slot,
> > int func)
> > {
> > u16 gmch_ctrl;
> > @@ -500,6 +512,11 @@ static const struct intel_early_ops
> > chv_early_ops __initconst = {
> > .stolen_size = chv_stolen_size,
> > };
> >
> > +static const struct intel_early_ops gen11_early_ops __initconst =
> > {
> > + .stolen_base = gen11_stolen_base,
> > + .stolen_size = gen9_stolen_size,
> > +};
> > +
> > static const struct pci_device_id intel_early_ids[] __initconst =
> > {
> > INTEL_I830_IDS(&i830_early_ops),
> > INTEL_I845G_IDS(&i845_early_ops),
> > @@ -531,6 +548,7 @@ static const struct pci_device_id
> > intel_early_ids[] __initconst = {
> > INTEL_CFL_IDS(&gen9_early_ops),
> > INTEL_GLK_IDS(&gen9_early_ops),
> > INTEL_CNL_IDS(&gen9_early_ops),
> > + INTEL_ICL_11_IDS(&gen11_early_ops),
> > };
>
> Please split the patch here and add a respective Fixes: tag to when
> base Icelake support was introduced. Lacking this portion when
> running ICL will
> cause random memory corruption so it's important to have this landed
> early.
Icelake is still hidden behind the alpha_support flag, so no point in
backporting for i915.ko specifically. If we're talking about
backporting just because of the memory reservation without graphics,
how far back should we go?
>
> Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: configure the transcoder clocks before touching pipeconf on HSW+ (rev2)
Em Qua, 2018-05-02 às 22:23 +, Patchwork escreveu: > == Series Details == > > Series: drm/i915: configure the transcoder clocks before touching > pipeconf on HSW+ (rev2) > URL : https://patchwork.freedesktop.org/series/42436/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4125 -> Patchwork_8884 = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_8884 absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the > changes > introduced in Patchwork_8884, please notify your bug team Can't the bot just give me the emails to cc? > to allow them > to document this new failure mode, which will reduce false > positives in CI. There were 2 runs for this series, both with different failures. The FBC one is caused by a FIFO underrun (which looks like we never properly fixed, and FBC is disabled on HSW anyway). In the other email there's a possible PNV regresison which definitely has nothing to do with this series. The other is a wedged GPU on module reload, which also doesn't seem to be caused by us. > > External URL: https://patchwork.freedesktop.org/api/1.0/series/4243 > 6/revisions/2/mbox/ > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_8884: > > === IGT changes === > > Possible regressions > > igt@kms_frontbuffer_tracking@basic: > fi-hsw-peppy: PASS -> DMESG-FAIL > > > == Known issues == > > Here are the changes found in Patchwork_8884 that come from known > issues: > > === IGT changes === > > Issues hit > > igt@gem_mmap_gtt@basic-small-bo-tiledx: > fi-gdg-551: PASS -> FAIL (fdo#102575) > > igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: > fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) > > > Possible fixes > > igt@kms_flip@basic-flip-vs-wf_vblank: > fi-hsw-4200u: FAIL (fdo#100368) -> PASS > > igt@kms_frontbuffer_tracking@basic: > fi-hsw-4200u: DMESG-FAIL (fdo#106103, fdo#102614) -> PASS > > igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: > fi-skl-6700k2: FAIL (fdo#103191) -> PASS > > > fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 > fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 > fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 > fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 > fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 > fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 > > > == Participating hosts (39 -> 37) == > > Additional (1): fi-byt-j1900 > Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq > > > == Build changes == > > * Linux: CI_DRM_4125 -> Patchwork_8884 > > CI_DRM_4125: c862a73270499cdd3d7c04c889e43303ae5f928e @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_4456: 43761534c6482dc67b9c3d8eeecd425ef40b3c4c @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_8884: 4a5b649073070534c7a0f7a1b828b2c3f7acd690 @ > git://anongit.freedesktop.org/gfx-ci/linux > piglit_4456: 30b992bdc047073e1fe99b1ac622f026618a8081 @ > git://anongit.freedesktop.org/piglit > > > == Linux commits == > > 4a5b64907307 drm/i915: enable the pipe/transcoder/planes later on > HSW+ > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchw > ork_8884/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] x86/gpu: reserve ICL's graphics stolen memory
ICL changes the registers and addresses to 64 bits.
I also briefly looked at implementing an u64 version of the PCI config
read functions, but I concluded this wouldn't be trivial, so it's not
worth doing it for a single user that can't have any racing problems
while reading the register in two separate operations.
v2:
- Scrub the development (non-public) changelog (Joonas).
- Remove the i915.ko bits so this can be easily backported in order
to properly avoid stolen memory even on machines without i915.ko
(Joonas).
- CC stable for the reasons above.
Issue: VIZ-9250
CC: sta...@vger.kernel.org
Cc: Ingo Molnar
Cc: H. Peter Anvin
Cc: x...@kernel.org
Cc: Daniele Ceraolo Spurio
Cc: Joonas Lahtinen
Signed-off-by: Paulo Zanoni
---
arch/x86/kernel/early-quirks.c | 18 ++
include/drm/i915_drm.h | 4 +++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index bae0d32e327b..72c2cf961d44 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -340,6 +340,18 @@ static resource_size_t __init gen3_stolen_base(int num,
int slot, int func,
return bsm & INTEL_BSM_MASK;
}
+static resource_size_t __init gen11_stolen_base(int num, int slot, int func,
+ resource_size_t stolen_size)
+{
+ u64 bsm;
+
+ bsm = read_pci_config(num, slot, func, INTEL_GEN11_BSM_DW0);
+ bsm &= INTEL_BSM_MASK;
+ bsm |= (u64)read_pci_config(num, slot, func, INTEL_GEN11_BSM_DW1) << 32;
+
+ return bsm;
+}
+
static resource_size_t __init i830_stolen_size(int num, int slot, int func)
{
u16 gmch_ctrl;
@@ -500,6 +512,11 @@ static const struct intel_early_ops chv_early_ops
__initconst = {
.stolen_size = chv_stolen_size,
};
+static const struct intel_early_ops gen11_early_ops __initconst = {
+ .stolen_base = gen11_stolen_base,
+ .stolen_size = gen9_stolen_size,
+};
+
static const struct pci_device_id intel_early_ids[] __initconst = {
INTEL_I830_IDS(&i830_early_ops),
INTEL_I845G_IDS(&i845_early_ops),
@@ -531,6 +548,7 @@ static const struct pci_device_id intel_early_ids[]
__initconst = {
INTEL_CFL_IDS(&gen9_early_ops),
INTEL_GLK_IDS(&gen9_early_ops),
INTEL_CNL_IDS(&gen9_early_ops),
+ INTEL_ICL_11_IDS(&gen11_early_ops),
};
struct resource intel_graphics_stolen_res __ro_after_init = DEFINE_RES_MEM(0,
0);
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index c9e5a6621b95..c44703f471b3 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -95,7 +95,9 @@ extern struct resource intel_graphics_stolen_res;
#defineI845_TSEG_SIZE_512K (2 << 1)
#defineI845_TSEG_SIZE_1M (3 << 1)
-#define INTEL_BSM 0x5c
+#define INTEL_BSM 0x5c
+#define INTEL_GEN11_BSM_DW00xc0
+#define INTEL_GEN11_BSM_DW10xc4
#define INTEL_BSM_MASK (-(1u << 20))
#endif /* _I915_DRM_H_ */
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: use the ICL stolen memory
Now that our stolen memory is already reserved by the x86 subsystem
(since commit "x86/gpu: reserve ICL's graphics stolen memory"), make
use of it.
Cc: Joonas Lahtinen
Cc: Daniele Ceraolo Spurio
Cc: x...@kernel.org
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 38 +-
drivers/gpu/drm/i915/i915_reg.h| 1 +
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index ad949cc30928..99556f0dbedc 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -343,6 +343,35 @@ static void bdw_get_stolen_reserved(struct
drm_i915_private *dev_priv,
*size = stolen_top - *base;
}
+static void icl_get_stolen_reserved(struct drm_i915_private *dev_priv,
+ resource_size_t *base,
+ resource_size_t *size)
+{
+ u64 reg_val = I915_READ64(GEN6_STOLEN_RESERVED);
+
+ DRM_DEBUG_DRIVER("GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
+
+ *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
+
+ switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
+ case GEN8_STOLEN_RESERVED_1M:
+ *size = 1024 * 1024;
+ break;
+ case GEN8_STOLEN_RESERVED_2M:
+ *size = 2 * 1024 * 1024;
+ break;
+ case GEN8_STOLEN_RESERVED_4M:
+ *size = 4 * 1024 * 1024;
+ break;
+ case GEN8_STOLEN_RESERVED_8M:
+ *size = 8 * 1024 * 1024;
+ break;
+ default:
+ *size = 8 * 1024 * 1024;
+ MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
+ }
+}
+
int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
{
resource_size_t reserved_base, stolen_top;
@@ -399,7 +428,9 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
gen7_get_stolen_reserved(dev_priv,
&reserved_base,
&reserved_size);
break;
- default:
+ case 8:
+ case 9:
+ case 10:
if (IS_LP(dev_priv))
chv_get_stolen_reserved(dev_priv,
&reserved_base, &reserved_size);
@@ -407,6 +438,11 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
bdw_get_stolen_reserved(dev_priv,
&reserved_base, &reserved_size);
break;
+ case 11:
+ default:
+ icl_get_stolen_reserved(dev_priv, &reserved_base,
+ &reserved_size);
+ break;
}
/*
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 15daf3553d40..c5bc7c808e31 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -398,6 +398,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN8_STOLEN_RESERVED_4M(2 << 7)
#define GEN8_STOLEN_RESERVED_8M(3 << 7)
#define GEN6_STOLEN_RESERVED_ENABLE(1 << 0)
+#define GEN11_STOLEN_RESERVED_ADDR_MASK(0xFFFULL << 20)
/* VGA stuff */
--
2.14.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Read the correct Gen11 interrupt registers
Em Qui, 2018-05-10 às 14:59 -0700, Oscar Mateo escreveu:
> Stop reading some now deprecated interrupt registers in both
> debugfs and error state. Instead, read the new equivalents in the
> Gen11 interrupt repartitioning scheme.
>
> Note that the equivalent to the PM ISR & IIR cannot be read without
> affecting the current state of the system, so I've opted for leaving
> them out. See gen11_service_one_iir() for more info.
I can't find this function. Did you mean something else?
>
> v2: else if !!! (Paulo)
> v3: another else if (Vinay)
> v4:
> - Rebased
> - Renamed patch
> - Improved the ordering of GENs
> - Improved the printing of per-GEN info
> v5: Avoid maybe-unitialized & add comment explaining the lack
> of PM ISR & IIR
>
> Suggested-by: Paulo Zanoni
> Signed-off-by: Oscar Mateo
> Cc: Tvrtko Ursulin
> Cc: Daniele Ceraolo Spurio
> Cc: Sagar Arun Kamble
> Cc: Vinay Belgaumkar
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 34 -
> -
> drivers/gpu/drm/i915/i915_gpu_error.c | 11 ++-
> drivers/gpu/drm/i915/i915_gpu_error.h | 2 +-
> 3 files changed, 35 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d663a9e0..d992dd2 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1170,19 +1170,28 @@ static int i915_frequency_info(struct
> seq_file *m, void *unused)
>
> intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
>
> - if (IS_GEN6(dev_priv) || IS_GEN7(dev_priv)) {
> - pm_ier = I915_READ(GEN6_PMIER);
> - pm_imr = I915_READ(GEN6_PMIMR);
> - pm_isr = I915_READ(GEN6_PMISR);
> - pm_iir = I915_READ(GEN6_PMIIR);
> - pm_mask = I915_READ(GEN6_PMINTRMSK);
> - } else {
> + if (INTEL_GEN(dev_priv) >= 11) {
> + pm_ier =
> I915_READ(GEN11_GPM_WGBOXPERF_INTR_ENABLE);
> + pm_imr =
> I915_READ(GEN11_GPM_WGBOXPERF_INTR_MASK);
> + /*
> + * The equivalent to the PM ISR & IIR cannot
> be read
> + * without affecting the current state of
> the system
> + */
> + pm_isr = 0;
> + pm_iir = 0;
> + } else if (INTEL_GEN(dev_priv) >= 8) {
> pm_ier = I915_READ(GEN8_GT_IER(2));
> pm_imr = I915_READ(GEN8_GT_IMR(2));
> pm_isr = I915_READ(GEN8_GT_ISR(2));
> pm_iir = I915_READ(GEN8_GT_IIR(2));
> - pm_mask = I915_READ(GEN6_PMINTRMSK);
> + } else {
> + pm_ier = I915_READ(GEN6_PMIER);
> + pm_imr = I915_READ(GEN6_PMIMR);
> + pm_isr = I915_READ(GEN6_PMISR);
> + pm_iir = I915_READ(GEN6_PMIIR);
> }
> + pm_mask = I915_READ(GEN6_PMINTRMSK);
> +
> seq_printf(m, "Video Turbo Mode: %s\n",
> yesno(rpmodectl & GEN6_RP_MEDIA_TURBO));
> seq_printf(m, "HW control enabled: %s\n",
> @@ -1190,8 +1199,13 @@ static int i915_frequency_info(struct seq_file
> *m, void *unused)
> seq_printf(m, "SW control enabled: %s\n",
> yesno((rpmodectl &
> GEN6_RP_MEDIA_MODE_MASK) ==
> GEN6_RP_MEDIA_SW_MODE));
> - seq_printf(m, "PM IER=0x%08x IMR=0x%08x ISR=0x%08x
> IIR=0x%08x, MASK=0x%08x\n",
> -pm_ier, pm_imr, pm_isr, pm_iir, pm_mask);
> +
> + seq_printf(m, "PM IER=0x%08x IMR=0x%08x,
> MASK=0x%08x\n",
> +pm_ier, pm_imr, pm_mask);
> + if (INTEL_GEN(dev_priv) < 11) {
> + seq_printf(m, "PM ISR=0x%08x IIR=0x%08x\n",
> +pm_isr, pm_iir);
> + }
> seq_printf(m, "pm_intrmsk_mbz: 0x%08x\n",
> rps->pm_intrmsk_mbz);
> seq_printf(m, "GT_PERF_STATUS: 0x%08x\n",
> gt_perf_status);
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index b98cd44..d9f2f69 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1675,7 +1675,16 @@ static void capture_reg_state(struct
> i915_gpu_state *error)
> }
[Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns
Ever since I started working on FBC I was already aware that FBC can
really amplify the FIFO underrun symptoms. On systems where FIFO
underruns were harmless error messages, enabling FBC would cause the
underruns to give black screens.
We recently tried to enable FBC on Haswell and got reports of a system
that would hang after some hours of uptime, and the first bad commit
was the one that enabled FBC. We also observed that this system had
FIFO underrun error messages on its dmesg. Although we don't have any
evidence that fixing the underruns would solve the bug and make FBC
work properly on this machine, IMHO it's better if we minimize the
amount of possible problems by just giving up FBC whenever we detect
an underrun.
v2: New version, different implementation and commit message.
v3: Clarify the fact that we run from an IRQ handler (Chris).
Cc: Stefan Richter
Cc: Lyude
Cc: stevenhoney...@gmail.com
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h| 3 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbc.c | 61 ++
drivers/gpu/drm/i915/intel_fifo_underrun.c | 2 +
4 files changed, 67 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 35caa9b..baa9c66 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -941,6 +941,9 @@ struct intel_fbc {
bool enabled;
bool active;
+ bool underrun_detected;
+ struct work_struct underrun_work;
+
struct intel_fbc_state_cache {
struct {
unsigned int mode_flags;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1c700b0..50c1eb0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1494,6 +1494,7 @@ void intel_fbc_invalidate(struct drm_i915_private
*dev_priv,
void intel_fbc_flush(struct drm_i915_private *dev_priv,
unsigned int frontbuffer_bits, enum fb_op_origin origin);
void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
+void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv);
/* intel_hdmi.c */
void intel_hdmi_init(struct drm_device *dev, i915_reg_t hdmi_reg, enum port
port);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index e122052..950aed5 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -750,6 +750,13 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
struct intel_fbc *fbc = &dev_priv->fbc;
struct intel_fbc_state_cache *cache = &fbc->state_cache;
+ /* We don't need to use a state cache here since this information is
+* global for every CRTC. */
+ if (fbc->underrun_detected) {
+ fbc->no_fbc_reason = "underrun detected";
+ return false;
+ }
+
if (!cache->plane.visible) {
fbc->no_fbc_reason = "primary plane not visible";
return false;
@@ -1193,6 +1200,59 @@ void intel_fbc_global_disable(struct drm_i915_private
*dev_priv)
cancel_work_sync(&fbc->work.work);
}
+static void intel_fbc_underrun_work_fn(struct work_struct *work)
+{
+ struct drm_i915_private *dev_priv =
+ container_of(work, struct drm_i915_private, fbc.underrun_work);
+ struct intel_fbc *fbc = &dev_priv->fbc;
+
+ mutex_lock(&fbc->lock);
+
+ /* Maybe we were scheduled twice. */
+ if (fbc->underrun_detected)
+ goto out;
+
+ DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
+ fbc->underrun_detected = true;
+
+ intel_fbc_deactivate(dev_priv);
+out:
+ mutex_unlock(&fbc->lock);
+}
+
+/**
+ * intel_fbc_handle_fifo_underrun_irq - disable FBC when we get a FIFO underrun
+ * @dev_priv: i915 device instance
+ *
+ * Without FBC, most underruns are harmless and don't really cause too many
+ * problems, except for an annoying message on dmesg. With FBC, underruns can
+ * become black screens or even worse, especially when paired with bad
+ * watermarks. So in order for us to be on the safe side, completely disable
FBC
+ * in case we ever detect a FIFO underrun on any pipe. An underrun on any pipe
+ * already suggests that watermarks may be bad, so try to be as safe as
+ * possible.
+ *
+ * This function is called from the IRQ handler.
+ */
+void intel_fbc_handle_fifo_underrun_irq(struct drm_i915_private *dev_priv)
+{
+ struct intel_fbc *fbc = &dev_priv->fbc;
+
+ if (!fbc_supported(dev_priv))
+ return;
+
+ /* There's no guarantee that underrun_detected won't be set to true
+* right after this check and before the work is scheduled, but that's
+* not a p
[Intel-gfx] [PATCH] drm/i915: Call intel_fbc_pre_update() after pinning the new pageflip
From: Chris Wilson
intel_fbc_pre_update() depends upon the new state being already pinned
in place in the Global GTT (primarily for both fencing which wants both
an offset and a fence register, if assigned). This requires the call to
intel_fbc_pre_update() be after intel_pin_and_fence_fb() - but commit
e8216e502aca ("drm/i915/fbc: call intel_fbc_pre_update earlier during
page flips") moved the code way too much up in its attempt to call it
before the page flip.
v2 (from Paulo):
- Point the original bad commit.
- Add a comment to maybe prevent further regressions.
Fixes: e8216e502aca ("drm/i915/fbc: call intel_fbc_pre_update earlier...")
Signed-off-by: Chris Wilson
Signed-off-by: Paulo Zanoni
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Patrik Jakobsson
Cc: drm-intel-fi...@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8a203b5..7057bd9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12109,9 +12109,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
crtc->primary->fb = fb;
update_state_fb(crtc->primary);
- intel_fbc_pre_update(intel_crtc, intel_crtc->config,
-to_intel_plane_state(primary->state));
-
work->pending_flip_obj = i915_gem_object_get(obj);
ret = i915_mutex_lock_interruptible(dev);
@@ -12157,6 +12154,17 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
work->gtt_offset += intel_crtc->dspaddr_offset;
work->rotation = crtc->primary->state->rotation;
+ /*
+* There's the potential that the next frame will not be compatible with
+* FBC, so we want to call pre_update() before the actual page flip.
+* The problem is that pre_update() caches some information about the fb
+* object, so we want to do this only after the object is pinned. Let's
+* be on the safe side and do this immediately before scheduling the
+* flip.
+*/
+ intel_fbc_pre_update(intel_crtc, intel_crtc->config,
+to_intel_plane_state(primary->state));
+
if (mmio_flip) {
INIT_WORK(&work->mmio_work, intel_mmio_flip_work_func);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: don't forget to set intel_crtc->dspaddr_offset on SKL+
We never remembered to set it (so it was zero), but this was not a
problem in the past due to the way handled the hardware registers.
Unfortunately we changed how we set the hardware and forgot to set
intel_crtc->dspaddr_offset.
This started to reflect on a few kms_frontbuffer_tracking subtests
that relied on page flips with CRTCs that don't point to the x:0,y:0
coordinates of the frontbuffer. After the page flip the CRTC was
showing the x:0,y:0 coordinate of the frontbuffer instead of
x:500,y:500. This problem is present even if we don't enable FBC or
PSR.
While trying to bisect it I realized that the first bad commit
actually just gives me a black screen for the mentioned tests instead
of showing the wrong x:0,y:0 offsets. A few commits later the black
screen problem goes away and we get to the point where the code is
today, but I'll consider the black screen as the first bad commit
since it's the point where the IGT subtests start to fail.
Fixes: 6687c9062c46 ("drm/i915: Rewrite fb rotation GTT handling")
Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-pgflip-blt
Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-evflip-blt
Testcase: kms_frontbuffer_tracking/fbc-1p-shrfb-fliptrack
Cc: Ville Syrjälä
Cc: Sivakumar Thulasimani
Cc: drm-intel-fi...@lists.freedesktop.org
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f3e9ac5..1232b0e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3407,6 +3407,8 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
dst_w--;
dst_h--;
+ intel_crtc->dspaddr_offset = surf_addr;
+
intel_crtc->adjusted_x = src_x;
intel_crtc->adjusted_y = src_y;
--
2.7.4
___
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/fbc: Allow on unfenced surfaces, for recent gen
2016-08-18 5:21 GMT-03:00 Chris Wilson :
> Only fbc1 is tied to using a fence. Later iterations of fbc are more
> flexible and allow operation on unfenced frontbuffers.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: "Zanoni, Paulo R"
Hi
I see this patch was applied. Now, on my Skylake machine, if I boot
with i915.enable_fbc=1 I'll get FIFO underruns under fbcon. Just
booting already gives me a FIFO underrun message, and then if I "sudo
systemctl stop lightdm" I'll get a constantly-blinking screen.
Of course, applying the patch that disables FBC after a FIFO underrun
will help stopping the ever-blinking fbcon, but I think we should try
to avoid the underruns in the places we know we can, and leave the
"disable FBC on FIFO underruns" just for the cases we're not expecting.
Also, please remember that I mentioned there are FBC workarounds for
untiled that we still don't implement (although when I re-read my
email it may sound like I suggested the workarounds are for non-GTT
tracking). IMHO this argument alone should
have prevented this patch from being merged...
Based on that, can we please revert this patch? I'm afraid some people
would consider these underruns as blockers to enabling FBC, so it's
probably better to enable FBC only on X tiled for now, and leave this
for when we know how to prevent the underrun (possibly by implementing
the missing WAs).
(I'm sorry if you got this message twice, but the mail servers are a
little crazy these days and I didn't receive my copy, so I'm sending
it again).
Thanks,
Paulo
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 57e1ca624d73..9534f90c6551 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -789,8 +789,10 @@ static bool intel_fbc_can_activate(struct intel_crtc
> *crtc)
> */
> if (cache->fb.tiling_mode != I915_TILING_X ||
> cache->fb.fence_reg == I915_FENCE_REG_NONE) {
> - fbc->no_fbc_reason = "framebuffer not tiled or fenced";
> - return false;
> + if (INTEL_GEN(dev_priv) < 5) {
> + fbc->no_fbc_reason = "framebuffer not tiled or
> fenced";
> + return false;
> + }
> }
> if (INTEL_INFO(dev_priv)->gen <= 4 && !IS_G4X(dev_priv) &&
> cache->plane.rotation != DRM_ROTATE_0) {
> --
> 2.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915/gen9: fix the watermark res_blocks value
We forgot the "res_blocks += y_tile_minimum" that's described on step
V of our documentation.
Again, this should only affect the Y tiling cases.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 70dc0c4..381c482 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3556,7 +3556,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint8_t cpp;
uint32_t width = 0, height = 0;
uint32_t plane_pixel_rate;
- uint32_t y_min_scanlines;
+ uint32_t y_tile_minimum, y_min_scanlines;
if (latency == 0 || !cstate->base.active ||
!intel_pstate->base.visible) {
*enabled = false;
@@ -3613,10 +3613,10 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
latency,
plane_blocks_per_line);
+ y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
+
if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
- uint32_t y_tile_minimum = plane_blocks_per_line *
- y_min_scanlines;
selected_result = max(method2, y_tile_minimum);
} else {
if ((ddb_allocation / plane_blocks_per_line) >= 1)
@@ -3630,10 +3630,12 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
if (level >= 1 && level <= 7) {
if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
- fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED)
+ fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
+ res_blocks += y_tile_minimum;
res_lines += y_min_scanlines;
- else
+ } else {
res_blocks++;
+ }
}
if (res_blocks >= ddb_allocation || res_lines > 31) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations
The confusing thing is that plane_blocks_per_line is listed as part of
the method 2 calculation but is also used for other things. We
calculated it in two different places and different ways: one inside
skl_wm_method2() and the other inside skl_compute_plane_wm(). The
skl_wm_method2() implementation is the one that matches the
specification.
With this patch we fix the skl_compute_plane_wm() calculation and just
pass it as a parameter to skl_wm_method2(). We also take care to not
modify the value of plane_bytes_per_line since we're going to rely on
it having a correct value in later patches.
This should affect the watermarks for Linear and Y-tiled.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 39 +++
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5a23a91..70dc0c4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3498,30 +3498,14 @@ static uint32_t skl_wm_method1(uint32_t pixel_rate,
uint8_t cpp, uint32_t latenc
}
static uint32_t skl_wm_method2(uint32_t pixel_rate, uint32_t pipe_htotal,
- uint32_t horiz_pixels, uint8_t cpp,
- uint64_t tiling, uint32_t latency,
- uint32_t y_min_scanlines)
+ uint32_t latency, uint32_t plane_blocks_per_line)
{
uint32_t ret;
- uint32_t plane_bytes_per_line, plane_blocks_per_line;
uint32_t wm_intermediate_val;
if (latency == 0)
return UINT_MAX;
- plane_bytes_per_line = horiz_pixels * cpp;
-
- if (tiling == I915_FORMAT_MOD_Y_TILED ||
- tiling == I915_FORMAT_MOD_Yf_TILED) {
- plane_bytes_per_line *= y_min_scanlines;
- plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
- plane_blocks_per_line /= y_min_scanlines;
- } else if (tiling == DRM_FORMAT_MOD_NONE) {
- plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512)
+ 1;
- } else {
- plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
- }
-
wm_intermediate_val = latency * pixel_rate;
ret = DIV_ROUND_UP(wm_intermediate_val, pipe_htotal * 1000) *
plane_blocks_per_line;
@@ -3610,17 +3594,24 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
y_min_scanlines = 4;
}
+ plane_bytes_per_line = width * cpp;
+ if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
+ fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
+ plane_blocks_per_line =
+ DIV_ROUND_UP(plane_bytes_per_line * y_min_scanlines, 512);
+ plane_blocks_per_line /= y_min_scanlines;
+ } else if (fb->modifier[0] == DRM_FORMAT_MOD_NONE) {
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512)
+ + 1;
+ } else {
+ plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+ }
+
method1 = skl_wm_method1(plane_pixel_rate, cpp, latency);
method2 = skl_wm_method2(plane_pixel_rate,
cstate->base.adjusted_mode.crtc_htotal,
-width,
-cpp,
-fb->modifier[0],
latency,
-y_min_scanlines);
-
- plane_bytes_per_line = width * cpp;
- plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+plane_blocks_per_line);
if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] SKL/KBL watermark fixes
Hi This series is the result of me comparing the code against BSpec. It doesn't solve any particular problem I was seeing, but there's enough changes that this code could potentially change the watermarks values for most machines. Maybe this will fix somebody's underrun? Even if it doesn't, we should still have a code that matches the specification unless there's a big justification. I still didn't finish reviewing everything and there's at least one workaround that we seem to be missing, but let's try to get these patches merged first. Thanks, Paulo Cc: Lyude Cc: Matt Roper Cc: Mahesh Kumar Paulo Zanoni (8): drm/i915: SAGV is not SKL-only, so rename a few things drm/i915: introduce intel_has_sagv() drm/i915/kbl: KBL also needs to run the SAGV code drm/i915/gen9: fix the WaWmMemoryReadLatency implementation drm/i915/gen9: minimum scanlines for Y tile is not always 4 drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations drm/i915/gen9: fix the watermark res_blocks value drm/i915/gen9: implement missing case for SKL watermarks calculation drivers/gpu/drm/i915/i915_drv.h | 10 +- drivers/gpu/drm/i915/intel_display.c | 9 +- drivers/gpu/drm/i915/intel_drv.h | 6 +- drivers/gpu/drm/i915/intel_pm.c | 177 --- 4 files changed, 111 insertions(+), 91 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915/gen9: implement missing case for SKL watermarks calculation
This should affect linear and X tiled planes on really small htotal
cases. It doesn't seem to be a very feasible case, but let's implement
it since it's on the specification and it's better to have it and
never need than not have it and realize we needed it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 381c482..86c6d66 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3619,7 +3619,10 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
selected_result = max(method2, y_tile_minimum);
} else {
- if ((ddb_allocation / plane_blocks_per_line) >= 1)
+ if ((cpp * cstate->base.adjusted_mode.crtc_htotal / 512 < 1) &&
+ (plane_bytes_per_line / 512 < 1))
+ selected_result = method2;
+ else if ((ddb_allocation / plane_blocks_per_line) >= 1)
selected_result = min(method1, method2);
else
selected_result = method1;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915: introduce intel_has_sagv()
And use it to move knowledge about the SAGV-supporting platforms from
the callers to the SAGV code.
We'll add more platforms to intel_has_sagv(), so IMHO it makes more
sense to move all this to a single function instead of patching all
the callers every time we add SAGV support to a new platform.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 5 ++---
drivers/gpu/drm/i915/intel_pm.c | 15 +++
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4dd4961..2442ab2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14379,7 +14379,7 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
* SKL workaround: bspec recommends we disable the SAGV when we
* have more then one pipe enabled
*/
- if (IS_SKYLAKE(dev_priv) && !intel_can_enable_sagv(state))
+ if (!intel_can_enable_sagv(state))
intel_disable_sagv(dev_priv);
intel_modeset_verify_disabled(dev);
@@ -14437,8 +14437,7 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
intel_modeset_verify_crtc(crtc, old_crtc_state, crtc->state);
}
- if (IS_SKYLAKE(dev_priv) && intel_state->modeset &&
- intel_can_enable_sagv(state))
+ if (intel_state->modeset && intel_can_enable_sagv(state))
intel_enable_sagv(dev_priv);
drm_atomic_helper_commit_hw_done(state);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 32588e3..af75011 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2884,6 +2884,12 @@ skl_wm_plane_id(const struct intel_plane *plane)
}
}
+static bool
+intel_has_sagv(struct drm_i915_private *dev_priv)
+{
+ return IS_SKYLAKE(dev_priv);
+}
+
/*
* SAGV dynamically adjusts the system agent voltage and clock frequencies
* depending on power and performance requirements. The display engine access
@@ -2900,6 +2906,9 @@ intel_enable_sagv(struct drm_i915_private *dev_priv)
{
int ret;
+ if (!intel_has_sagv(dev_priv))
+ return 0;
+
if (dev_priv->sagv_status == I915_SAGV_NOT_CONTROLLED ||
dev_priv->sagv_status == I915_SAGV_ENABLED)
return 0;
@@ -2949,6 +2958,9 @@ intel_disable_sagv(struct drm_i915_private *dev_priv)
{
int ret, result;
+ if (!intel_has_sagv(dev_priv))
+ return 0;
+
if (dev_priv->sagv_status == I915_SAGV_NOT_CONTROLLED ||
dev_priv->sagv_status == I915_SAGV_DISABLED)
return 0;
@@ -2991,6 +3003,9 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
enum pipe pipe;
int level, plane;
+ if (!intel_has_sagv(dev_priv))
+ return false;
+
/*
* SKL workaround: bspec recommends we disable the SAGV when we have
* more then one pipe enabled
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915/gen9: minimum scanlines for Y tile is not always 4
During watermarks calculations, this value is used in 3 different
places. Only one of them was not using a hardcoded 4. Move the code up
so everybody can benefit from the actual value.
This should only help on situations with Y tiling + 90/270 rotation +
1 or 2 bpp or NV12.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 56 +++--
1 file changed, 32 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f8ac928..5a23a91 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3499,7 +3499,8 @@ static uint32_t skl_wm_method1(uint32_t pixel_rate,
uint8_t cpp, uint32_t latenc
static uint32_t skl_wm_method2(uint32_t pixel_rate, uint32_t pipe_htotal,
uint32_t horiz_pixels, uint8_t cpp,
- uint64_t tiling, uint32_t latency)
+ uint64_t tiling, uint32_t latency,
+ uint32_t y_min_scanlines)
{
uint32_t ret;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
@@ -3512,9 +3513,9 @@ static uint32_t skl_wm_method2(uint32_t pixel_rate,
uint32_t pipe_htotal,
if (tiling == I915_FORMAT_MOD_Y_TILED ||
tiling == I915_FORMAT_MOD_Yf_TILED) {
- plane_bytes_per_line *= 4;
+ plane_bytes_per_line *= y_min_scanlines;
plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
- plane_blocks_per_line /= 4;
+ plane_blocks_per_line /= y_min_scanlines;
} else if (tiling == DRM_FORMAT_MOD_NONE) {
plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512)
+ 1;
} else {
@@ -3571,6 +3572,7 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint8_t cpp;
uint32_t width = 0, height = 0;
uint32_t plane_pixel_rate;
+ uint32_t y_min_scanlines;
if (latency == 0 || !cstate->base.active ||
!intel_pstate->base.visible) {
*enabled = false;
@@ -3586,38 +3588,44 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
cpp = drm_format_plane_cpp(fb->pixel_format, 0);
plane_pixel_rate = skl_adjusted_plane_pixel_rate(cstate, intel_pstate);
+ if (intel_rotation_90_or_270(pstate->rotation)) {
+ int cpp = (fb->pixel_format == DRM_FORMAT_NV12) ?
+ drm_format_plane_cpp(fb->pixel_format, 1) :
+ drm_format_plane_cpp(fb->pixel_format, 0);
+
+ switch (cpp) {
+ case 1:
+ y_min_scanlines = 16;
+ break;
+ case 2:
+ y_min_scanlines = 8;
+ break;
+ default:
+ WARN(1, "Unsupported pixel depth for rotation");
+ case 4:
+ y_min_scanlines = 4;
+ break;
+ }
+ } else {
+ y_min_scanlines = 4;
+ }
+
method1 = skl_wm_method1(plane_pixel_rate, cpp, latency);
method2 = skl_wm_method2(plane_pixel_rate,
cstate->base.adjusted_mode.crtc_htotal,
width,
cpp,
fb->modifier[0],
-latency);
+latency,
+y_min_scanlines);
plane_bytes_per_line = width * cpp;
plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
- uint32_t min_scanlines = 4;
- uint32_t y_tile_minimum;
- if (intel_rotation_90_or_270(pstate->rotation)) {
- int cpp = (fb->pixel_format == DRM_FORMAT_NV12) ?
- drm_format_plane_cpp(fb->pixel_format, 1) :
- drm_format_plane_cpp(fb->pixel_format, 0);
-
- switch (cpp) {
- case 1:
- min_scanlines = 16;
- break;
- case 2:
- min_scanlines = 8;
- break;
- case 8:
- WARN(1, "Unsupported pixel depth for rotation");
- }
- }
- y_tile_minimum = plane_blocks_per_line * min_scanlines;
+ uint32_t y_tile_minimum = plane_blocks_per_line *
+ y_min_scanlines;
selected_result = max(method2, y_tile_minimum);
} e
[Intel-gfx] [PATCH 1/8] drm/i915: SAGV is not SKL-only, so rename a few things
The plan is to introduce intel_has_sagv() and then use it to discover
which platforms actually support it.
I thought about keeping the functions with their current skl names,
but found two problems: (i) skl_has_sagv() would become a very
confusing name, and (ii) intel_atomic_commit_tail() doesn't seem to be
calling any functions whose name start with a platform name, so the
"intel_" naming scheme seems make more sense than the "firstplatorm_"
naming scheme here.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 10 +-
drivers/gpu/drm/i915/intel_display.c | 8
drivers/gpu/drm/i915/intel_drv.h | 6 +++---
drivers/gpu/drm/i915/intel_pm.c | 26 +-
4 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 053a347..503c69d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1972,11 +1972,11 @@ struct drm_i915_private {
struct vlv_s0ix_state vlv_s0ix_state;
enum {
- I915_SKL_SAGV_UNKNOWN = 0,
- I915_SKL_SAGV_DISABLED,
- I915_SKL_SAGV_ENABLED,
- I915_SKL_SAGV_NOT_CONTROLLED
- } skl_sagv_status;
+ I915_SAGV_UNKNOWN = 0,
+ I915_SAGV_DISABLED,
+ I915_SAGV_ENABLED,
+ I915_SAGV_NOT_CONTROLLED
+ } sagv_status;
struct {
/*
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6b4d7ac..4dd4961 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14379,8 +14379,8 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
* SKL workaround: bspec recommends we disable the SAGV when we
* have more then one pipe enabled
*/
- if (IS_SKYLAKE(dev_priv) && !skl_can_enable_sagv(state))
- skl_disable_sagv(dev_priv);
+ if (IS_SKYLAKE(dev_priv) && !intel_can_enable_sagv(state))
+ intel_disable_sagv(dev_priv);
intel_modeset_verify_disabled(dev);
}
@@ -14438,8 +14438,8 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
}
if (IS_SKYLAKE(dev_priv) && intel_state->modeset &&
- skl_can_enable_sagv(state))
- skl_enable_sagv(dev_priv);
+ intel_can_enable_sagv(state))
+ intel_enable_sagv(dev_priv);
drm_atomic_helper_commit_hw_done(state);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d084c1b..bb55b61 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1741,9 +1741,9 @@ void ilk_wm_get_hw_state(struct drm_device *dev);
void skl_wm_get_hw_state(struct drm_device *dev);
void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
struct skl_ddb_allocation *ddb /* out */);
-bool skl_can_enable_sagv(struct drm_atomic_state *state);
-int skl_enable_sagv(struct drm_i915_private *dev_priv);
-int skl_disable_sagv(struct drm_i915_private *dev_priv);
+bool intel_can_enable_sagv(struct drm_atomic_state *state);
+int intel_enable_sagv(struct drm_i915_private *dev_priv);
+int intel_disable_sagv(struct drm_i915_private *dev_priv);
bool skl_ddb_allocation_equals(const struct skl_ddb_allocation *old,
const struct skl_ddb_allocation *new,
enum pipe pipe);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4f833a0..32588e3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2896,12 +2896,12 @@ skl_wm_plane_id(const struct intel_plane *plane)
* - We're not using an interlaced display configuration
*/
int
-skl_enable_sagv(struct drm_i915_private *dev_priv)
+intel_enable_sagv(struct drm_i915_private *dev_priv)
{
int ret;
- if (dev_priv->skl_sagv_status == I915_SKL_SAGV_NOT_CONTROLLED ||
- dev_priv->skl_sagv_status == I915_SKL_SAGV_ENABLED)
+ if (dev_priv->sagv_status == I915_SAGV_NOT_CONTROLLED ||
+ dev_priv->sagv_status == I915_SAGV_ENABLED)
return 0;
DRM_DEBUG_KMS("Enabling the SAGV\n");
@@ -2919,19 +2919,19 @@ skl_enable_sagv(struct drm_i915_private *dev_priv)
*/
if (ret == -ENXIO) {
DRM_DEBUG_DRIVER("No SAGV found on system, ignoring\n");
- dev_priv->skl_sagv_status = I915_SKL_SAGV_NOT_CONTROLLED;
+ dev_priv->sagv_status = I915_SAGV_NOT_CONTROLLED;
return 0;
} else if (ret < 0) {
DRM_ERROR("Failed to enable the SAGV\n");
[Intel-gfx] [PATCH 4/8] drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
Bspec says:
"The mailbox response data may not account for memory read latency.
If the mailbox response data for level 0 is 0us, add 2 microseconds
to the result for each valid level."
This means we should only do the +2 in case wm[0] == 0, not always.
So split the sanitizing implementation from the WA implementation and
fix the WA implementation.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 42 +
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index baacd95..f8ac928 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2127,32 +2127,34 @@ static void intel_read_wm_latency(struct drm_device
*dev, uint16_t wm[8])
GEN9_MEM_LATENCY_LEVEL_MASK;
/*
+* If a level n (n > 1) has a 0us latency, all levels m (m >= n)
+* need to be disabled. We make sure to sanitize the values out
+* of the punit to satisfy this requirement.
+*/
+ for (level = 1; level <= max_level; level++) {
+ if (wm[level] == 0) {
+ for (i = level + 1; i <= max_level; i++)
+ wm[i] = 0;
+ break;
+ }
+ }
+
+ /*
* WaWmMemoryReadLatency:skl
*
* punit doesn't take into account the read latency so we need
-* to add 2us to the various latency levels we retrieve from
-* the punit.
-* - W0 is a bit special in that it's the only level that
-* can't be disabled if we want to have display working, so
-* we always add 2us there.
-* - For levels >=1, punit returns 0us latency when they are
-* disabled, so we respect that and don't add 2us then
-*
-* Additionally, if a level n (n > 1) has a 0us latency, all
-* levels m (m >= n) need to be disabled. We make sure to
-* sanitize the values out of the punit to satisfy this
-* requirement.
+* to add 2us to the various latency levels we retrieve from the
+* punit when level 0 response data us 0us.
*/
- wm[0] += 2;
- for (level = 1; level <= max_level; level++)
- if (wm[level] != 0)
+ if (wm[0] == 0) {
+ wm[0] += 2;
+ for (level = 1; level <= max_level; level++) {
+ if (wm[level] == 0)
+ break;
wm[level] += 2;
- else {
- for (i = level + 1; i <= max_level; i++)
- wm[i] = 0;
-
- break;
}
+ }
+
} else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
uint64_t sskpd = I915_READ64(MCH_SSKPD);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915/kbl: KBL also needs to run the SAGV code
According to BSpec, it's the "core CPUs" that need the code, which
means SKL and KBL, but not BXT.
I don't have a KBL to test this patch on it.
Signed-off-by: Paulo Zanoni
---
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 af75011..baacd95 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2887,7 +2887,7 @@ skl_wm_plane_id(const struct intel_plane *plane)
static bool
intel_has_sagv(struct drm_i915_private *dev_priv)
{
- return IS_SKYLAKE(dev_priv);
+ return IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv);
}
/*
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+
BSpec does not show these WAs as applicable to GLK, and for CNL it
only shows them applicable for a super early pre-production stepping
we shouldn't be caring about anymore. Remove these so we can avoid
them on ICL too.
v2: Change how we check for gen9 display platforms (Ville).
Cc: Matt Roper
Reviewed-by: Ville Syrjälä
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 43 ++---
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9da8ff263d36..b5623a70c19c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4754,28 +4754,31 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
res_lines = div_round_up_fixed16(selected_result,
wp->plane_blocks_per_line);
- /* Display WA #1125: skl,bxt,kbl,glk */
- if (level == 0 && wp->rc_surface)
- res_blocks += fixed16_to_u32_round_up(wp->y_tile_minimum);
+ if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) {
+ /* Display WA #1125: skl,bxt,kbl */
+ if (level == 0 && wp->rc_surface)
+ res_blocks +=
+ fixed16_to_u32_round_up(wp->y_tile_minimum);
+
+ /* Display WA #1126: skl,bxt,kbl */
+ if (level >= 1 && level <= 7) {
+ if (wp->y_tiled) {
+ res_blocks +=
+ fixed16_to_u32_round_up(wp->y_tile_minimum);
+ res_lines += wp->y_min_scanlines;
+ } else {
+ res_blocks++;
+ }
- /* Display WA #1126: skl,bxt,kbl,glk */
- if (level >= 1 && level <= 7) {
- if (wp->y_tiled) {
- res_blocks += fixed16_to_u32_round_up(
- wp->y_tile_minimum);
- res_lines += wp->y_min_scanlines;
- } else {
- res_blocks++;
+ /*
+* Make sure result blocks for higher latency levels are
+* atleast as high as level below the current level.
+* Assumption in DDB algorithm optimization for special
+* cases. Also covers Display WA #1125 for RC.
+*/
+ if (result_prev->plane_res_b > res_blocks)
+ res_blocks = result_prev->plane_res_b;
}
-
- /*
-* Make sure result blocks for higher latency levels are atleast
-* as high as level below the current level.
-* Assumption in DDB algorithm optimization for special cases.
-* Also covers Display WA #1125 for RC.
-*/
- if (result_prev->plane_res_b > res_blocks)
- res_blocks = result_prev->plane_res_b;
}
if (INTEL_GEN(dev_priv) >= 11) {
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations
BSpec was updated and now there's no more "subtract 1" to the
Microsecond Counter Divider field.
It seems this should help fixing some GMBUS issues. I'm not aware of
any specific open bug that could be solved by this patch.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_cdclk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 8d74276029e6..810670976e86 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2660,7 +2660,7 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
fraction = 200;
}
- rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
+ rawclk = CNP_RAWCLK_DIV(divider / 1000);
if (fraction)
rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
fraction) - 1);
@@ -2676,12 +2676,12 @@ static int icp_rawclk(struct drm_i915_private *dev_priv)
if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
frequency = 24000;
- divider = 23;
+ divider = 24;
numerator = 0;
denominator = 0;
} else {
frequency = 19200;
- divider = 18;
+ divider = 19;
numerator = 1;
denominator = 4;
}
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()
I think I'm probably the one who argued in favor of having separate
implementations for both PCHs, but the calculations are actually the
same, the clocks are the same and the only difference is that on ICP
we write the numerator to the register.
I have previously suggested to kill cnp_rawclk() and keep the
icp_rawclk() style, but Ville gave some good arguments that what's in
this patch may be the better choice.
Cc: Ville Syrjälä
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_cdclk.c | 37 -
1 file changed, 8 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 928671936286..60437675354e 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2661,36 +2661,17 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
}
rawclk = CNP_RAWCLK_DIV(divider / 1000);
- if (fraction)
- rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
- fraction) - 1);
+ if (fraction) {
+ int numerator = 1000;
- I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
- return divider + fraction;
-}
-
-static int icp_rawclk(struct drm_i915_private *dev_priv)
-{
- u32 rawclk;
- int divider, numerator, denominator, frequency;
-
- if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
- frequency = 24000;
- divider = 24;
- numerator = 0;
- denominator = 0;
- } else {
- frequency = 19200;
- divider = 19;
- numerator = 1;
- denominator = 4;
+ rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(numerator,
+ fraction) - 1);
+ if (HAS_PCH_ICP(dev_priv))
+ rawclk |= ICP_RAWCLK_NUM(numerator / 1000);
}
- rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-CNP_RAWCLK_DEN(denominator);
-
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
- return frequency;
+ return divider + fraction;
}
static int pch_rawclk(struct drm_i915_private *dev_priv)
@@ -2740,9 +2721,7 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
*/
void intel_update_rawclk(struct drm_i915_private *dev_priv)
{
- if (HAS_PCH_ICP(dev_priv))
- dev_priv->rawclk_freq = icp_rawclk(dev_priv);
- else if (HAS_PCH_CNP(dev_priv))
+ if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv))
dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: rename CNP_RAWCLK_FRAC to CNP_RAWCLK_DEN
Although CNP names this field "Counter Fraction", what we write to the
register is really the denominator for the fractional part of the
divider, not the fractional part (and the field description even says
that). The ICP spec renamed the field to "Counter Fraction
Denominator", which makes a lot more sense. Use the more complete ICL
naming because we will merge the CNP and ICP functions into a single
one, which will introduce the concept of the numerator. That will make
a lot more sense when you read the "num/frac = den" calculation.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h| 3 +--
drivers/gpu/drm/i915/intel_cdclk.c | 6 +++---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fe4b913e46ac..16f0d73bb4fe 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7907,8 +7907,7 @@ enum {
#define CNP_RAWCLK_DIV_MASK (0x3ff << 16)
#define CNP_RAWCLK_DIV(div) ((div) << 16)
#define CNP_RAWCLK_FRAC_MASK (0xf << 26)
-#define CNP_RAWCLK_FRAC(frac) ((frac) << 26)
-#define ICP_RAWCLK_DEN(den) ((den) << 26)
+#define CNP_RAWCLK_DEN(den) ((den) << 26)
#define ICP_RAWCLK_NUM(num) ((num) << 11)
#define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 810670976e86..928671936286 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2662,8 +2662,8 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
rawclk = CNP_RAWCLK_DIV(divider / 1000);
if (fraction)
- rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
- fraction) - 1);
+ rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
+ fraction) - 1);
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
return divider + fraction;
@@ -2687,7 +2687,7 @@ static int icp_rawclk(struct drm_i915_private *dev_priv)
}
rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-ICP_RAWCLK_DEN(denominator);
+CNP_RAWCLK_DEN(denominator);
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
return frequency;
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()
Em Seg, 2018-11-12 às 16:54 +0200, Ville Syrjälä escreveu:
> On Fri, Nov 09, 2018 at 04:23:50PM -0800, Paulo Zanoni wrote:
> > I think I'm probably the one who argued in favor of having separate
> > implementations for both PCHs, but the calculations are actually
> > the
> > same, the clocks are the same and the only difference is that on
> > ICP
> > we write the numerator to the register.
> >
> > I have previously suggested to kill cnp_rawclk() and keep the
> > icp_rawclk() style, but Ville gave some good arguments that what's
> > in
> > this patch may be the better choice.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/intel_cdclk.c | 37
> > -
> > 1 file changed, 8 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> > b/drivers/gpu/drm/i915/intel_cdclk.c
> > index 928671936286..60437675354e 100644
> > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > @@ -2661,36 +2661,17 @@ static int cnp_rawclk(struct
> > drm_i915_private *dev_priv)
> > }
> >
> > rawclk = CNP_RAWCLK_DIV(divider / 1000);
> > - if (fraction)
> > - rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
> > - fractio
> > n) - 1);
> > + if (fraction) {
> > + int numerator = 1000;
> >
> > - I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
> > - return divider + fraction;
> > -}
> > -
> > -static int icp_rawclk(struct drm_i915_private *dev_priv)
> > -{
> > - u32 rawclk;
> > - int divider, numerator, denominator, frequency;
> > -
> > - if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
> > - frequency = 24000;
> > - divider = 24;
> > - numerator = 0;
> > - denominator = 0;
> > - } else {
> > - frequency = 19200;
> > - divider = 19;
> > - numerator = 1;
> > - denominator = 4;
> > + rawclk |=
> > CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(numerator,
> > + fractio
> > n) - 1);
> > + if (HAS_PCH_ICP(dev_priv))
> > + rawclk |= ICP_RAWCLK_NUM(numerator /
> > 1000);
>
> Maybe
> int numerator = 1;
> ...
> DIV_ROUND_CLOSEST(numerator * 1000, ... ?
Will do. I guess I tried to keep the logic of "local variables should
be in KHz and conversion to MHz goes inside the reg-writing macros",
but I don't feel it is better or worse than the suggestion.
>
> The fixed numerator is OK since we only have to support 19.2 for
> now. If in the future we get more frequencies we may want to make
> this more flexible. But not much point in worrying about that now.
>
> Series is
> Reviewed-by: Ville Syrjälä
Thanks a lot. Sorry for the huge delay in the follow-up.
>
> > }
> >
> > - rawclk = CNP_RAWCLK_DIV(divider) |
> > ICP_RAWCLK_NUM(numerator) |
> > -CNP_RAWCLK_DEN(denominator);
> > -
> > I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
> > - return frequency;
> > + return divider + fraction;
> > }
> >
> > static int pch_rawclk(struct drm_i915_private *dev_priv)
> > @@ -2740,9 +2721,7 @@ static int g4x_hrawclk(struct
> > drm_i915_private *dev_priv)
> > */
> > void intel_update_rawclk(struct drm_i915_private *dev_priv)
> > {
> > - if (HAS_PCH_ICP(dev_priv))
> > - dev_priv->rawclk_freq = icp_rawclk(dev_priv);
> > - else if (HAS_PCH_CNP(dev_priv))
> > + if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv))
> > dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
> > else if (HAS_PCH_SPLIT(dev_priv))
> > dev_priv->rawclk_freq = pch_rawclk(dev_priv);
> > --
> > 2.14.4
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3 v2] drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()
I think I'm probably the one who argued in favor of having separate
implementations for both PCHs, but the calculations are actually the
same, the clocks are the same and the only difference is that on ICP
we write the numerator to the register.
I have previously suggested to kill cnp_rawclk() and keep the
icp_rawclk() style, but Ville gave some good arguments that what's in
this patch may be the better choice.
v2: Switch numerator to 1 from 1000 and adjust calculations
accordingly (Ville).
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_cdclk.c | 37 -
1 file changed, 8 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 928671936286..25e3aba9cded 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2661,36 +2661,17 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
}
rawclk = CNP_RAWCLK_DIV(divider / 1000);
- if (fraction)
- rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
- fraction) - 1);
+ if (fraction) {
+ int numerator = 1;
- I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
- return divider + fraction;
-}
-
-static int icp_rawclk(struct drm_i915_private *dev_priv)
-{
- u32 rawclk;
- int divider, numerator, denominator, frequency;
-
- if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
- frequency = 24000;
- divider = 24;
- numerator = 0;
- denominator = 0;
- } else {
- frequency = 19200;
- divider = 19;
- numerator = 1;
- denominator = 4;
+ rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(numerator * 1000,
+ fraction) - 1);
+ if (HAS_PCH_ICP(dev_priv))
+ rawclk |= ICP_RAWCLK_NUM(numerator);
}
- rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-CNP_RAWCLK_DEN(denominator);
-
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
- return frequency;
+ return divider + fraction;
}
static int pch_rawclk(struct drm_i915_private *dev_priv)
@@ -2740,9 +2721,7 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
*/
void intel_update_rawclk(struct drm_i915_private *dev_priv)
{
- if (HAS_PCH_ICP(dev_priv))
- dev_priv->rawclk_freq = icp_rawclk(dev_priv);
- else if (HAS_PCH_CNP(dev_priv))
+ if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv))
dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/3] drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()
I think I'm probably the one who argued in favor of having separate
implementations for both PCHs, but the calculations are actually the
same, the clocks are the same and the only difference is that on ICP
we write the numerator to the register.
I have previously suggested to kill cnp_rawclk() and keep the
icp_rawclk() style, but Ville gave some good arguments that what's in
this patch may be the better choice.
v2: Switch numerator to 1 from 1000 and adjust calculations
accordingly (Ville).
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_cdclk.c | 37 -
1 file changed, 8 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 928671936286..25e3aba9cded 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2661,36 +2661,17 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
}
rawclk = CNP_RAWCLK_DIV(divider / 1000);
- if (fraction)
- rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
- fraction) - 1);
+ if (fraction) {
+ int numerator = 1;
- I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
- return divider + fraction;
-}
-
-static int icp_rawclk(struct drm_i915_private *dev_priv)
-{
- u32 rawclk;
- int divider, numerator, denominator, frequency;
-
- if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
- frequency = 24000;
- divider = 24;
- numerator = 0;
- denominator = 0;
- } else {
- frequency = 19200;
- divider = 19;
- numerator = 1;
- denominator = 4;
+ rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(numerator * 1000,
+ fraction) - 1);
+ if (HAS_PCH_ICP(dev_priv))
+ rawclk |= ICP_RAWCLK_NUM(numerator);
}
- rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-CNP_RAWCLK_DEN(denominator);
-
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
- return frequency;
+ return divider + fraction;
}
static int pch_rawclk(struct drm_i915_private *dev_priv)
@@ -2740,9 +2721,7 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
*/
void intel_update_rawclk(struct drm_i915_private *dev_priv)
{
- if (HAS_PCH_ICP(dev_priv))
- dev_priv->rawclk_freq = icp_rawclk(dev_priv);
- else if (HAS_PCH_CNP(dev_priv))
+ if (HAS_PCH_CNP(dev_priv) || HAS_PCH_ICP(dev_priv))
dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915: rename CNP_RAWCLK_FRAC to CNP_RAWCLK_DEN
Although CNP names this field "Counter Fraction", what we write to the
register is really the denominator for the fractional part of the
divider, not the fractional part (and the field description even says
that). The ICP spec renamed the field to "Counter Fraction
Denominator", which makes a lot more sense. Use the more complete ICL
naming because we will merge the CNP and ICP functions into a single
one, which will introduce the concept of the numerator. That will make
a lot more sense when you read the "num/frac = den" calculation.
Reviewed-by: Ville Syrjälä
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h| 3 +--
drivers/gpu/drm/i915/intel_cdclk.c | 6 +++---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fe4b913e46ac..16f0d73bb4fe 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7907,8 +7907,7 @@ enum {
#define CNP_RAWCLK_DIV_MASK (0x3ff << 16)
#define CNP_RAWCLK_DIV(div) ((div) << 16)
#define CNP_RAWCLK_FRAC_MASK (0xf << 26)
-#define CNP_RAWCLK_FRAC(frac) ((frac) << 26)
-#define ICP_RAWCLK_DEN(den) ((den) << 26)
+#define CNP_RAWCLK_DEN(den) ((den) << 26)
#define ICP_RAWCLK_NUM(num) ((num) << 11)
#define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 810670976e86..928671936286 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2662,8 +2662,8 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
rawclk = CNP_RAWCLK_DIV(divider / 1000);
if (fraction)
- rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
- fraction) - 1);
+ rawclk |= CNP_RAWCLK_DEN(DIV_ROUND_CLOSEST(1000,
+ fraction) - 1);
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
return divider + fraction;
@@ -2687,7 +2687,7 @@ static int icp_rawclk(struct drm_i915_private *dev_priv)
}
rawclk = CNP_RAWCLK_DIV(divider) | ICP_RAWCLK_NUM(numerator) |
-ICP_RAWCLK_DEN(denominator);
+CNP_RAWCLK_DEN(denominator);
I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
return frequency;
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915/cnp+: update to the new RAWCLK_FREQ recommendations
BSpec was updated and now there's no more "subtract 1" to the
Microsecond Counter Divider field.
It seems this should help fixing some GMBUS issues. I'm not aware of
any specific open bug that could be solved by this patch.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Reviewed-by: Ville Syrjälä
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_cdclk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
b/drivers/gpu/drm/i915/intel_cdclk.c
index 8d74276029e6..810670976e86 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -2660,7 +2660,7 @@ static int cnp_rawclk(struct drm_i915_private *dev_priv)
fraction = 200;
}
- rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
+ rawclk = CNP_RAWCLK_DIV(divider / 1000);
if (fraction)
rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
fraction) - 1);
@@ -2676,12 +2676,12 @@ static int icp_rawclk(struct drm_i915_private *dev_priv)
if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
frequency = 24000;
- divider = 23;
+ divider = 24;
numerator = 0;
denominator = 0;
} else {
frequency = 19200;
- divider = 18;
+ divider = 19;
numerator = 1;
denominator = 4;
}
--
2.14.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: don't apply Display WAs 1125 and 1126 to GLK/CNL+
BSpec does not show these WAs as applicable to GLK, and for CNL it
only shows them applicable for a super early pre-production stepping
we shouldn't be caring about anymore. Remove these so we can avoid
them on ICL too.
v2: Change how we check for gen9 display platforms (Ville).
Cc: Matt Roper
Reviewed-by: Ville Syrjälä
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 43 ++---
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27498ded4949..18914c4ca070 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4755,28 +4755,31 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
res_lines = div_round_up_fixed16(selected_result,
wp->plane_blocks_per_line);
- /* Display WA #1125: skl,bxt,kbl,glk */
- if (level == 0 && wp->rc_surface)
- res_blocks += fixed16_to_u32_round_up(wp->y_tile_minimum);
+ if (IS_GEN9_BC(dev_priv) || IS_BROXTON(dev_priv)) {
+ /* Display WA #1125: skl,bxt,kbl */
+ if (level == 0 && wp->rc_surface)
+ res_blocks +=
+ fixed16_to_u32_round_up(wp->y_tile_minimum);
+
+ /* Display WA #1126: skl,bxt,kbl */
+ if (level >= 1 && level <= 7) {
+ if (wp->y_tiled) {
+ res_blocks +=
+ fixed16_to_u32_round_up(wp->y_tile_minimum);
+ res_lines += wp->y_min_scanlines;
+ } else {
+ res_blocks++;
+ }
- /* Display WA #1126: skl,bxt,kbl,glk */
- if (level >= 1 && level <= 7) {
- if (wp->y_tiled) {
- res_blocks += fixed16_to_u32_round_up(
- wp->y_tile_minimum);
- res_lines += wp->y_min_scanlines;
- } else {
- res_blocks++;
+ /*
+* Make sure result blocks for higher latency levels are
+* atleast as high as level below the current level.
+* Assumption in DDB algorithm optimization for special
+* cases. Also covers Display WA #1125 for RC.
+*/
+ if (result_prev->plane_res_b > res_blocks)
+ res_blocks = result_prev->plane_res_b;
}
-
- /*
-* Make sure result blocks for higher latency levels are atleast
-* as high as level below the current level.
-* Assumption in DDB algorithm optimization for special cases.
-* Also covers Display WA #1125 for RC.
-*/
- if (result_prev->plane_res_b > res_blocks)
- res_blocks = result_prev->plane_res_b;
}
if (INTEL_GEN(dev_priv) >= 11) {
--
2.17.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
