Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/i915/display: change pipe order for platforms with big joiner
Date: Tue, 18 Nov 2025 19:40:06 +0200	[thread overview]
Message-ID: <aRyvdsdmuS7LvI1F@intel.com> (raw)
In-Reply-To: <0989b7647aef0c1dfacbdd302e5b3720d3a558c4@intel.com>

On Tue, Nov 18, 2025 at 03:43:35PM +0200, Jani Nikula wrote:
> On Tue, 18 Nov 2025, Jani Nikula <jani.nikula@intel.com> wrote:
> > When big joiner is enabled, it reserves the adjacent pipe as the
> > secondary pipe. This happens without the user space knowing, and
> > subsequent attempts at using the CRTC with that pipe will fail. If the
> > user space does not have a coping mechanism, i.e. trying another pipe,
> > this leads to a black screen.
> >
> > If the platform allows joining A+B, map the CRTCs to pipes in order A,
> > C, B, and D to trick userspace to using pipes that are more likely to be
> > available for joining.
> >
> > Although there are currently no platforms with more than four pipes, add
> > a fallback for initializing the rest of the pipes to not miss them.
> >
> > v2: Also remove WARN_ON()
> 
> There's still this in intel_atomic_check_joiner():
> 
> 		/*
> 		 * The state copy logic assumes the primary crtc gets processed
> 		 * before the secondary crtc during the main compute_config loop.
> 		 * This works because the crtcs are created in pipe order,
> 		 * and the hardware requires primary pipe < secondary pipe as well.
> 		 * Should that change we need to rethink the logic.
> 		 */
> 		if (WARN_ON(drm_crtc_index(&primary_crtc->base) >
> 			    drm_crtc_index(&secondary_crtc->base)))
> 			return -EINVAL;
> 
> This still works for A+B and C+D joining, but will fail loudly for B+C
> joining.
> 
> Ideas?

Hmm, I think I got rid of that requirement semi-accidentally in
commit 3a5e09d82f97 ("drm/i915: Fix intel_modeset_pipe_config_late() for
bigjoiner")

So it looks to me like we can just drop that check entirely.

> 
> BR,
> Jani.
> 
> 
> >
> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> >
> > ---
> >
> > Let's see what breaks...
> > ---
> >  drivers/gpu/drm/i915/display/intel_crtc.c     |  2 --
> >  .../drm/i915/display/intel_display_driver.c   | 26 ++++++++++++++++++-
> >  2 files changed, 25 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index 9d2a23c96c61..11e58d07ddef 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -394,8 +394,6 @@ int intel_crtc_init(struct intel_display *display, enum pipe pipe)
> >  
> >  	cpu_latency_qos_add_request(&crtc->vblank_pm_qos, PM_QOS_DEFAULT_VALUE);
> >  
> > -	drm_WARN_ON(display->drm, drm_crtc_index(&crtc->base) != crtc->pipe);
> > -
> >  	if (HAS_CASF(display))
> >  		drm_crtc_create_sharpness_strength_property(&crtc->base);
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c b/drivers/gpu/drm/i915/display/intel_display_driver.c
> > index 7e000ba3e08b..83aad727017b 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> > @@ -452,6 +452,7 @@ bool intel_display_driver_check_access(struct intel_display *display)
> >  /* part #2: call after irq install, but before gem init */
> >  int intel_display_driver_probe_nogem(struct intel_display *display)
> >  {
> > +	u8 pipe_mask = U8_MAX;
> >  	enum pipe pipe;
> >  	int ret;
> >  
> > @@ -470,7 +471,30 @@ int intel_display_driver_probe_nogem(struct intel_display *display)
> >  		    INTEL_NUM_PIPES(display),
> >  		    INTEL_NUM_PIPES(display) > 1 ? "s" : "");
> >  
> > -	for_each_pipe(display, pipe) {
> > +	/*
> > +	 * If we have a joiner that can join A+B, expose the pipes in order A,
> > +	 * C, B, D to trick user space into using pipes that are more likely to
> > +	 * be available for both a) user space if pipe B has been reserved for
> > +	 * the joiner, and b) the joiner if pipe A doesn't need the joiner.
> > +	 *
> > +	 * Fall back to normal initialization for the remaining pipes, if any.
> > +	 */
> > +	if (HAS_BIGJOINER(display) && DISPLAY_VER(display) >= 12) {
> > +		enum pipe pipe_order[] = { PIPE_A, PIPE_C, PIPE_B, PIPE_D };
> > +		int i;
> > +
> > +		for (i = 0; i < ARRAY_SIZE(pipe_order); i++) {
> > +			pipe = pipe_order[i];
> > +
> > +			ret = intel_crtc_init(display, pipe);
> > +			if (ret)
> > +				goto err_mode_config;
> > +
> > +			pipe_mask &= ~BIT(pipe);
> > +		}
> > +	}
> > +
> > +	for_each_pipe_masked(display, pipe, pipe_mask) {
> >  		ret = intel_crtc_init(display, pipe);
> >  		if (ret)
> >  			goto err_mode_config;
> 
> -- 
> Jani Nikula, Intel

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2025-11-18 17:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18  9:58 [PATCH] drm/i915/display: change pipe order for platforms with big joiner Jani Nikula
2025-11-18 13:37 ` [PATCH v2] " Jani Nikula
2025-11-18 13:43   ` Jani Nikula
2025-11-18 17:40     ` Ville Syrjälä [this message]
2025-11-18 19:34       ` Ville Syrjälä
2025-11-19 13:09         ` Jani Nikula
2025-11-19 18:36           ` Ville Syrjälä
2025-11-18 15:44 ` ✓ CI.KUnit: success for drm/i915/display: change pipe order for platforms with big joiner (rev2) Patchwork
2025-11-19  8:05 ` Patchwork
2025-11-19  8:35 ` ✗ Xe.CI.Full: failure " Patchwork
2025-11-19  8:59 ` ✗ Xe.CI.BAT: " 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=aRyvdsdmuS7LvI1F@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@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