From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Navare, Manasi" <manasi.d.navare@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 10/10] drm/i915: Change bigjoiner state tracking to use the pipe bitmask
Date: Mon, 7 Feb 2022 09:31:19 +0200 [thread overview]
Message-ID: <YgDKx8obYfeLKCAf@intel.com> (raw)
In-Reply-To: <20220204235828.GA23624@labuser-Z97X-UD5H>
On Fri, Feb 04, 2022 at 03:58:29PM -0800, Navare, Manasi wrote:
> On Thu, Feb 03, 2022 at 08:38:23PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Get rid of the inflexible bigjoiner_linked_crtc pointer thing
> > and just track things as a bitmask of pipes instead. We can
> > also nuke the bigjoiner_slave boolean as the role of the pipe
> > can be determined from its position in the bitmask.
> >
> > It might be possible to nuke the bigjoiner boolean as well
> > if we make encoder.compute_config() do the bitmask assignment
> > directly for the master pipe. But for now I left that alone so
> > that encoer.compute_config() will just flag the state as needing
> > bigjoiner, and the intel_atomic_check_bigjoiner() is still
> > responsible for determining the bitmask. But that may have to change
> > as the encoder may be in the best position to determine how
> > exactly we should populate the bitmask.
> >
> > Most places that just looked at the single bigjoiner_linked_crtc
> > now iterate over the whole bitmask, eliminating the singular
> > slave pipe assumption.
>
> Okay so trying to understand the design here:
> For Pipe A + B Bigjoiner and C + D bigjoiner for example,
> bitmasks will be as below:
>
> A : 0011
> B: 0011
>
> C: 1100
> D: 1100
>
> Is this correct understanding? Because we would mark both the master pipe and slave pipe in a bitmask right?
Yes.
>
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 5 +-
> > drivers/gpu/drm/i915/display/intel_ddi.c | 12 +-
> > drivers/gpu/drm/i915/display/intel_display.c | 305 ++++++++++++------
> > drivers/gpu/drm/i915/display/intel_display.h | 2 +
> > .../drm/i915/display/intel_display_debugfs.c | 5 +-
> > .../drm/i915/display/intel_display_types.h | 7 +-
> > .../drm/i915/display/intel_plane_initial.c | 7 -
> > drivers/gpu/drm/i915/display/intel_vdsc.c | 43 ---
> > drivers/gpu/drm/i915/display/intel_vdsc.h | 1 -
> > 9 files changed, 227 insertions(+), 160 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index 41d52889dfce..0e15fe908855 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -404,9 +404,10 @@ int intel_plane_atomic_check(struct intel_atomic_state *state,
> > intel_atomic_get_new_crtc_state(state, crtc);
> >
> > if (new_crtc_state && intel_crtc_is_bigjoiner_slave(new_crtc_state)) {
> > + struct intel_crtc *master_crtc =
> > + intel_master_crtc(new_crtc_state);
> > struct intel_plane *master_plane =
> > - intel_crtc_get_plane(new_crtc_state->bigjoiner_linked_crtc,
> > - plane->id);
> > + intel_crtc_get_plane(master_crtc, plane->id);
> >
> > new_master_plane_state =
> > intel_atomic_get_new_plane_state(state, master_plane);
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 3f0e1e127595..9dee12986991 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -2703,6 +2703,7 @@ static void intel_ddi_post_disable(struct intel_atomic_state *state,
> > struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> > bool is_tc_port = intel_phy_is_tc(dev_priv, phy);
> > + struct intel_crtc *slave_crtc;
> >
> > if (!intel_crtc_has_type(old_crtc_state, INTEL_OUTPUT_DP_MST)) {
> > intel_crtc_vblank_off(old_crtc_state);
> > @@ -2721,9 +2722,8 @@ static void intel_ddi_post_disable(struct intel_atomic_state *state,
> > ilk_pfit_disable(old_crtc_state);
> > }
> >
> > - if (old_crtc_state->bigjoiner_linked_crtc) {
> > - struct intel_crtc *slave_crtc =
> > - old_crtc_state->bigjoiner_linked_crtc;
> > + for_each_intel_crtc_in_pipe_mask(&dev_priv->drm, slave_crtc,
> > + intel_crtc_bigjoiner_slave_pipes(old_crtc_state)) {
> > const struct intel_crtc_state *old_slave_crtc_state =
> > intel_atomic_get_old_crtc_state(state, slave_crtc);
> >
> > @@ -3041,6 +3041,7 @@ intel_ddi_update_prepare(struct intel_atomic_state *state,
> > struct intel_encoder *encoder,
> > struct intel_crtc *crtc)
> > {
> > + struct drm_i915_private *i915 = to_i915(state->base.dev);
> > struct intel_crtc_state *crtc_state =
> > crtc ? intel_atomic_get_new_crtc_state(state, crtc) : NULL;
> > int required_lanes = crtc_state ? crtc_state->lane_count : 1;
> > @@ -3050,11 +3051,12 @@ intel_ddi_update_prepare(struct intel_atomic_state *state,
> > intel_tc_port_get_link(enc_to_dig_port(encoder),
> > required_lanes);
> > if (crtc_state && crtc_state->hw.active) {
> > - struct intel_crtc *slave_crtc = crtc_state->bigjoiner_linked_crtc;
> > + struct intel_crtc *slave_crtc;
> >
> > intel_update_active_dpll(state, crtc, encoder);
> >
> > - if (slave_crtc)
> > + for_each_intel_crtc_in_pipe_mask(&i915->drm, slave_crtc,
> > + intel_crtc_bigjoiner_slave_pipes(crtc_state))
> > intel_update_active_dpll(state, slave_crtc, encoder);
> > }
> > }
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> > index 34b6b4ab3a1b..f5fc283f8f73 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -337,20 +337,38 @@ is_trans_port_sync_mode(const struct intel_crtc_state *crtc_state)
> > is_trans_port_sync_slave(crtc_state);
> > }
> >
> > +static enum pipe bigjoiner_master_pipe(const struct intel_crtc_state *crtc_state)
> > +{
> > + return ffs(crtc_state->bigjoiner_pipes) - 1;
>
> Here we have both master and slave pipe bits set in a bitmask: This would result in ffs(0011) -1 = 2 which wouldnt be correct?
ffs(0b0011) == 1
<snip>
> > static int intel_atomic_check_bigjoiner(struct intel_atomic_state *state,
> > struct intel_crtc *master_crtc)
> > {
> > struct drm_i915_private *i915 = to_i915(state->base.dev);
> > struct intel_crtc_state *master_crtc_state =
> > intel_atomic_get_new_crtc_state(state, master_crtc);
> > - struct intel_crtc_state *slave_crtc_state;
> > struct intel_crtc *slave_crtc;
> > + u8 slave_pipes;
> >
> > - WARN_ON(master_crtc_state->bigjoiner_linked_crtc);
> > - WARN_ON(intel_crtc_is_bigjoiner_slave(master_crtc_state));
> > + /*
> > + * TODO: encoder.compute_config() may be the best
> > + * place to populate the bitmask for the master crtc.
> > + * For now encoder.compute_config() just flags things
> > + * as needing bigjoiner and we populate the bitmask
> > + * here.
> > + */
> > + WARN_ON(master_crtc_state->bigjoiner_pipes);
> >
> > if (!master_crtc_state->bigjoiner)
> > return 0;
> >
> > - slave_crtc = intel_dsc_get_bigjoiner_secondary(master_crtc);
> > - if (!slave_crtc) {
> > + slave_pipes = BIT(master_crtc->pipe + 1);
> > +
> > + if (slave_pipes & ~bigjoiner_pipes(i915)) {
> > drm_dbg_kms(&i915->drm,
> > - "[CRTC:%d:%s] Big joiner configuration requires "
> > - "CRTC + 1 to be used, doesn't exist\n",
> > + "[CRTC:%d:%s] Cannot act as big joiner master "
> > + "(need 0x%x as slave pipes, only 0x%x possible)\n",
> > + master_crtc->base.base.id, master_crtc->base.name,
> > + slave_pipes, bigjoiner_pipes(i915));
> > + return -EINVAL;
>
> I dont get how we are checking for the invalid slave pipe here?
> slave_pipes = BIT(1) = 0010
> bigjoiner_pipes = 0000 (since we havents et anything in compute config)
bigjoiner_pipes() is a bitmask of pipes that support bigjoiner.
It is constant for the platform.
> so slave_pipes & ~bigjoiner_pipes = 0010 & 1111 = 0010 so the condition will be true
> And then we are flagging it as error why?
If we come here with eg. master == pipe D on TGL then we'd
mark the non-existent pipe E as the slave. This check will
catch that.
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2022-02-07 7:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-03 18:38 [Intel-gfx] [PATCH 00/10] drm/i915: Use a bitmask for bigjoiner state tracking Ville Syrjala
2022-02-03 18:38 ` [Intel-gfx] [PATCH 01/10] drm/i915: Flag crtc scaling_filter changes as modeset Ville Syrjala
2022-02-03 21:58 ` Navare, Manasi
2022-02-04 6:53 ` Ville Syrjälä
2022-02-03 18:38 ` [Intel-gfx] [PATCH 02/10] drm/i915: Fix bigjoiner state copy fails Ville Syrjala
2022-02-03 22:13 ` Navare, Manasi
2022-02-04 7:05 ` Ville Syrjälä
2022-02-04 7:20 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2022-02-04 20:58 ` Navare, Manasi
2022-02-03 18:38 ` [Intel-gfx] [PATCH 03/10] drm/i915: Remove weird code from intel_atomic_check_bigjoiner() Ville Syrjala
2022-02-03 22:20 ` Navare, Manasi
2022-02-03 18:38 ` [Intel-gfx] [PATCH 04/10] drm/i915: Clean up the bigjoiner state copy logic Ville Syrjala
2022-02-04 7:20 ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2022-02-04 20:52 ` Navare, Manasi
2022-02-07 7:32 ` Ville Syrjälä
2022-02-03 18:38 ` [Intel-gfx] [PATCH 05/10] drm/i915: Nuke some dead code Ville Syrjala
2022-02-04 21:08 ` Navare, Manasi
2022-02-03 18:38 ` [Intel-gfx] [PATCH 06/10] drm/i915: Introduce intel_crtc_is_bigjoiner_{slave, master}() Ville Syrjala
2022-02-04 21:27 ` Navare, Manasi
2022-02-07 7:31 ` Ville Syrjälä
2022-02-15 10:53 ` Nautiyal, Ankit K
2022-02-03 18:38 ` [Intel-gfx] [PATCH 07/10] drm/i915: Convert for_each_intel_crtc_mask() to take a pipe mask instead Ville Syrjala
2022-02-09 19:57 ` Navare, Manasi
2022-02-03 18:38 ` [Intel-gfx] [PATCH 08/10] drm/i915: Use for_each_intel_crtc_in_pipe_mask() more Ville Syrjala
2022-02-09 19:58 ` Navare, Manasi
2022-02-03 18:38 ` [Intel-gfx] [PATCH 09/10] drm/i915: Return both master and slave pipes from enabled_bigjoiner_pipes() Ville Syrjala
2022-02-09 20:00 ` Navare, Manasi
2022-02-09 20:10 ` Ville Syrjälä
2022-02-03 18:38 ` [Intel-gfx] [PATCH 10/10] drm/i915: Change bigjoiner state tracking to use the pipe bitmask Ville Syrjala
2022-02-04 23:58 ` Navare, Manasi
2022-02-07 7:31 ` Ville Syrjälä [this message]
2022-02-07 23:56 ` Navare, Manasi
2022-02-03 18:50 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use a bitmask for bigjoiner state tracking Patchwork
2022-02-03 18:51 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-02-03 19:19 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-02-03 21:18 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-02-04 7:33 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use a bitmask for bigjoiner state tracking (rev3) Patchwork
2022-02-04 7:34 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-02-04 8:03 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-02-04 9:22 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-02-15 22:34 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Use a bitmask for bigjoiner state tracking (rev4) Patchwork
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=YgDKx8obYfeLKCAf@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=manasi.d.navare@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.