Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: intel-gfx@lists.freedesktop.org, jani.saarinen@intel.com
Subject: Re: [PATCH 2/5] drm/i915: Implement basic functions for ultrajoiner support
Date: Mon, 20 May 2024 21:24:45 +0300	[thread overview]
Message-ID: <ZkuVbZ8w6K5xoOnf@intel.com> (raw)
In-Reply-To: <20240520073839.23881-3-stanislav.lisovskiy@intel.com>

On Mon, May 20, 2024 at 10:38:36AM +0300, Stanislav Lisovskiy wrote:
> Lets implement or change basic functions required for ultrajoiner
> support from atomic commit/modesetting point of view.
> 
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 66 +++++++++++++++++---
>  1 file changed, 56 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index c74721188e59..c390b79a43d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -242,33 +242,65 @@ is_trans_port_sync_mode(const struct intel_crtc_state *crtc_state)
>  		is_trans_port_sync_slave(crtc_state);
>  }
>  
> -static enum pipe joiner_master_pipe(const struct intel_crtc_state *crtc_state)
> +static u8 joiner_master_pipes(const struct intel_crtc_state *crtc_state)
>  {
> -	return ffs(crtc_state->joiner_pipes) - 1;
> +	return BIT(PIPE_A) | BIT(PIPE_C);

Not a fan of the hardcoded pipes.

We could just do something like 
joiner_pipes & ((BIT(2) | BIT(0)) << joiner_master_pipe())
or some variant of that.

> +}
> +
> +static u8 joiner_primary_master_pipes(const struct intel_crtc_state *crtc_state)
> +{
> +	return BIT(PIPE_A);

This is just the joiner_master_pipe() we already have.

>  }
>  
>  u8 intel_crtc_joiner_slave_pipes(const struct intel_crtc_state *crtc_state)
>  {
> -	if (crtc_state->joiner_pipes)
> -		return crtc_state->joiner_pipes & ~BIT(joiner_master_pipe(crtc_state));
> +	if (intel_is_ultrajoiner(crtc_state))
> +		return crtc_state->joiner_pipes & ~joiner_primary_master_pipes(crtc_state);
> +	else if (intel_is_bigjoiner(crtc_state))
> +		return crtc_state->joiner_pipes & ~joiner_master_pipes(crtc_state);
>  	else
>  		return 0;

I don't see why this should make any distinction between bigjoiner
and ultrajoiner.

Either it returns everything that isn't the overall master, or it
returns just all the bigjoiner slave pipes. Which one we want
depends on the use case I guess. So we might need both variants.

>  }
>  
> -bool intel_crtc_is_joiner_slave(const struct intel_crtc_state *crtc_state)
> +bool intel_crtc_is_bigjoiner_slave(const struct intel_crtc_state *crtc_state)
>  {
>  	struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>  
>  	return crtc_state->joiner_pipes &&
> -		crtc->pipe != joiner_master_pipe(crtc_state);
> +		!(BIT(crtc->pipe) & joiner_master_pipes(crtc_state));

I'd probably add a joiner_slave_pipes() so that the logic is less
convoluted.

But I think first we need a solid agreement on the terminology,
and stick to it consistently.

Perhaps we need names for?
- the single master within the overall set of joined pipes
  (be it ultrajoiner master or the bigjoiner/uncompressed
   joiner master when ultrajoiner isn't used).
  Just call this joiner_master perhaps? Or perhaps just call it
  ultrajoiner_master but document that it is valid to use it
  also for the non-ultrajoiner cases.
- every other pipe in the set, ie. the inverse of above
  Should be just {ultra,}joiner_slaves to match the
  above I guess? Do we actually even need this? Not sure.

And the for the modeset sequencing we would perhaps need:
- all bigjoiner masters within the entire set of joined pipes
- all bigjoiner slaves within the entire set of joined pipes
  (inverse of the above)

The one slight snag here is that the "bigjoiner" name is
a bit incorrect for uncompressed joiner, but unless we want to
come up with some other name for these then I guess we'll just
have to live with it.

The other option is we try to come up with some generic names
for the two levels of pipe roles.

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2024-05-20 18:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-20  7:38 [PATCH 0/5] Ultrajoiner basic functionality series Stanislav Lisovskiy
2024-05-20  7:38 ` [PATCH 1/5] drm/i915: Rename all bigjoiner to joiner Stanislav Lisovskiy
2024-05-20 10:20   ` Jani Nikula
2024-05-20  7:38 ` [PATCH 2/5] drm/i915: Implement basic functions for ultrajoiner support Stanislav Lisovskiy
2024-05-20 18:24   ` Ville Syrjälä [this message]
2024-05-21  8:25     ` Lisovskiy, Stanislav
2024-05-21 18:09       ` Ville Syrjälä
2024-05-22  8:01         ` Lisovskiy, Stanislav
2024-05-22 11:40           ` Ville Syrjälä
2024-05-24  9:23             ` Lisovskiy, Stanislav
2024-05-20  7:38 ` [PATCH 3/5] drm/i915: Implement hw state readout for ultrajoiner Stanislav Lisovskiy
2024-05-20  7:38 ` [PATCH 4/5] drm/i915: Compute config and mode valid changes " Stanislav Lisovskiy
2024-05-21  4:28   ` kernel test robot
2024-05-20  7:38 ` [PATCH 5/5] drm/i915: Add new abstraction layer to handle pipe order for different joiners Stanislav Lisovskiy
2024-05-20 10:29 ` ✗ Fi.CI.CHECKPATCH: warning for Ultrajoiner basic functionality series Patchwork
2024-05-20 10:40 ` ✓ Fi.CI.BAT: success " Patchwork
2024-05-20 11:52 ` ✗ Fi.CI.IGT: failure " 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=ZkuVbZ8w6K5xoOnf@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.saarinen@intel.com \
    --cc=stanislav.lisovskiy@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox