From: "Lisovskiy, Stanislav" <stanislav.lisovskiy@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/i915/bigjoiner: Refactor bigjoiner state readout
Date: Mon, 15 Jan 2024 11:24:06 +0200 [thread overview]
Message-ID: <ZaT5tuo4FA/pZnjN@intel.com> (raw)
In-Reply-To: <ZaFr58MjVk261ADO@intel.com>
On Fri, Jan 12, 2024 at 06:42:15PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 08, 2024 at 02:07:24PM +0200, Stanislav Lisovskiy wrote:
> > Don't call enabled_bigjoiner_pipes twice, lets just move
> > intel_get_bigjoiner_config earlier, because it is anyway
> > calling same function.
> > Also cleanup hsw_enabled_transcoders from irrelevant bigjoiner code.
>
> It's not irrelevant. The function is supposed to return the set of
> enabled transcoders associated with the pipe. With this change the
> function no longer does what it says on the tin.
Yes, but I guess it is just a matter what we define to be higher in a
logical hierarchy: a pipe or a bigjoiner?
I thought it won't harm hsw_enabled_transcoders won't have any excess
logic and will return only transcoders naturally associated with a
physical pipe, while for higher complexity level constructs like bigjoiner
we would have some logic on top.
In fact my main motivation was to avoid calling enabled_bigjoiner_pipe as
it is quite heavy and call intel_crtc_is_bigjoiner_slave here instead.
enabled_bigjoiner_pipes reads too much information, which
we don't need in that function(here we just need to know if we are slave or master)
The absolute need for calling enabled_bigjoiner_pipes happens in
intel_bigjoiner_get_config, which we moved earlier, which seems to be
logical since hsw_get_transcoder_state needs to have bigjoiner info and
now we can use its results to call more lightweight intel_crtc_is_bigjoiner_slave there
because pipe_config->bigjoiner_pipes is now initialized, so we avoid calling enabled_bigjoiner_pipes
second time..
>
> >
> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 22 ++++++++++----------
> > 1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> > index 927d124457b61..eec76ec167069 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -3525,7 +3525,6 @@ static u8 hsw_enabled_transcoders(struct intel_crtc *crtc)
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > u8 panel_transcoder_mask = hsw_panel_transcoders(dev_priv);
> > enum transcoder cpu_transcoder;
> > - u8 master_pipes, slave_pipes;
> > u8 enabled_transcoders = 0;
> >
> > /*
> > @@ -3576,15 +3575,6 @@ static u8 hsw_enabled_transcoders(struct intel_crtc *crtc)
> > if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
> > enabled_transcoders |= BIT(cpu_transcoder);
> >
> > - /* bigjoiner slave -> consider the master pipe's transcoder as well */
> > - enabled_bigjoiner_pipes(dev_priv, &master_pipes, &slave_pipes);
> > - if (slave_pipes & BIT(crtc->pipe)) {
> > - cpu_transcoder = (enum transcoder)
> > - get_bigjoiner_master_pipe(crtc->pipe, master_pipes, slave_pipes);
> > - if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
> > - enabled_transcoders |= BIT(cpu_transcoder);
> > - }
> > -
> > return enabled_transcoders;
> > }
> >
> > @@ -3631,6 +3621,15 @@ static bool hsw_get_transcoder_state(struct intel_crtc *crtc,
> > u32 tmp;
> >
> > enabled_transcoders = hsw_enabled_transcoders(crtc);
> > +
> > + /* bigjoiner slave -> consider the master pipe's transcoder as well */
> > + if (intel_crtc_is_bigjoiner_slave(pipe_config)) {
> > + unsigned long cpu_transcoder = (enum transcoder)
> > + bigjoiner_master_pipe(pipe_config);
> > + if (transcoder_ddi_func_is_enabled(dev_priv, cpu_transcoder))
> > + enabled_transcoders |= BIT(cpu_transcoder);
> > + }
> > +
> > if (!enabled_transcoders)
> > return false;
> >
> > @@ -3735,6 +3734,8 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
> >
> > pipe_config->shared_dpll = NULL;
> >
> > + intel_bigjoiner_get_config(pipe_config);
>
> So this is what avoids the "call it twice" part, but it also makes the
> state potentially inconsistent as in all other cases we leave everything
> zeroed if the transcoder is not enabled. So I'm not sure this is
> entirely safe or whether we could end up with some weird state
> mismatches due to the inconsistency.
Isn't it vice versa? intel_bigjoiner_get_config is now called way earlier,
before hsw_get_transcoder_state is called(previously it was called later),
the only difference is just that we now have pipe_config->bigjoiner_pipes
filled and enabled_bigjoiner_pipes was called there, so we can now
use that info to call intel_crtc_is_bigjoiner_slave in hsw_get_transcoder_state,
as I mentioned above.
Also if none of the transcoders are enabled, we now in fact have more information
filled than before this change(before we had only enabled_bigjoiner_pipes called
in hsw_get_transcoder_state, but now we have also pipe_config->bigjoiner_pipes
initialized), otherwise if none of the transcoders are active everything should
be pretty much the same.
Stan
>
> Why do you think calling it twice is problematic? It's supposed to be
> idempotent (ignoring the actual register reads/etc.).
>
> > +
> > active = hsw_get_transcoder_state(crtc, pipe_config, &crtc->hw_readout_power_domains);
> >
> > if ((IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) &&
> > @@ -3746,7 +3747,6 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
> > if (!active)
> > goto out;
> >
> > - intel_bigjoiner_get_config(pipe_config);
> > intel_dsc_get_config(pipe_config);
> >
> > if (!transcoder_is_dsi(pipe_config->cpu_transcoder) ||
> > --
> > 2.37.3
>
> --
> Ville Syrjälä
> Intel
next prev parent reply other threads:[~2024-01-15 9:24 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-08 12:07 [PATCH 0/3] Bigjoiner refactoring Stanislav Lisovskiy
2024-01-08 12:07 ` [PATCH 1/3] drm/i915: Add bigjoiner force enable option to debugfs Stanislav Lisovskiy
2024-01-12 16:25 ` Ville Syrjälä
2024-01-15 8:57 ` Lisovskiy, Stanislav
2024-01-17 1:12 ` Manasi Navare
2024-01-18 11:02 ` Stanislav Lisovskiy
2024-01-18 11:53 ` Jani Nikula
2024-01-18 11:59 ` Lisovskiy, Stanislav
2024-01-29 8:28 ` Stanislav Lisovskiy
2024-01-08 12:07 ` [PATCH 2/3] drm/i915/bigjoiner: Refactor bigjoiner state readout Stanislav Lisovskiy
2024-01-12 16:42 ` Ville Syrjälä
2024-01-15 9:24 ` Lisovskiy, Stanislav [this message]
2024-01-08 12:07 ` [PATCH 3/3] Start separating pipe vs transcoder set logic for bigjoiner during modeset Stanislav Lisovskiy
2024-01-12 16:47 ` Ville Syrjälä
2024-01-15 9:27 ` Lisovskiy, Stanislav
2024-01-29 12:57 ` Lisovskiy, Stanislav
2024-02-02 10:02 ` Stanislav Lisovskiy
2024-02-07 16:27 ` Ville Syrjälä
2024-02-13 10:35 ` Stanislav Lisovskiy
2024-01-08 13:02 ` ✗ Fi.CI.CHECKPATCH: warning for Bigjoiner refactoring (rev2) Patchwork
2024-01-08 13:02 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-01-08 13:11 ` ✓ Fi.CI.BAT: success " Patchwork
2024-01-08 14:46 ` ✓ Fi.CI.IGT: " Patchwork
2024-01-18 20:41 ` ✗ Fi.CI.CHECKPATCH: warning for Bigjoiner refactoring (rev3) Patchwork
2024-01-18 20:41 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-01-18 20:55 ` ✓ Fi.CI.BAT: success " Patchwork
2024-01-19 9:16 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-01-29 12:26 ` ✓ Fi.CI.BAT: success for Bigjoiner refactoring (rev4) Patchwork
2024-01-29 12:26 ` ✗ Fi.CI.CHECKPATCH: warning " Patchwork
2024-01-29 12:26 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-01-30 0:59 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-02-02 18:00 ` ✗ Fi.CI.CHECKPATCH: warning for Bigjoiner refactoring (rev5) Patchwork
2024-02-02 18:29 ` ✗ Fi.CI.BAT: failure " Patchwork
2024-02-13 13:18 ` ✗ Fi.CI.CHECKPATCH: warning for Bigjoiner refactoring (rev6) Patchwork
2024-02-13 13:38 ` ✗ Fi.CI.BAT: failure " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2024-01-08 8:58 [PATCH 0/3] Bigjoiner refactoring Stanislav Lisovskiy
2024-01-08 8:58 ` [PATCH 2/3] drm/i915/bigjoiner: Refactor bigjoiner state readout Stanislav Lisovskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZaT5tuo4FA/pZnjN@intel.com \
--to=stanislav.lisovskiy@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.