Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Govindapillai, Vinod" <vinod.govindapillai@intel.com>
To: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Hogander, Jouni" <jouni.hogander@intel.com>
Cc: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>
Subject: Re: [PATCH 3/4] drm/i915/fbc: xe2_lpd+ don't require any hardcoded plane width limit
Date: Tue, 21 Jul 2026 11:00:41 +0000	[thread overview]
Message-ID: <38582f7a3e9032a64dc9cdffec5331c84098e4ca.camel@intel.com> (raw)
In-Reply-To: <9f270f8a27ac8d13648ab07621fd4fe609eadf45.camel@intel.com>

On Tue, 2026-07-21 at 12:47 +0300, Govindapillai, Vinod wrote:
> On Tue, 2026-07-21 at 09:01 +0000, Hogander, Jouni wrote:
> > On Fri, 2026-07-17 at 01:59 +0300, Vinod Govindapillai wrote:
> > > In xe2_lpd+ platforms, there are no restrictions to enable FBC
> > > on planes with respect to the plane width - width can be as per
> > > the platform's maximum supported resolution.
> > 
> > I would stick in display version. Xe2_lpd+ says nothing to me.
> 
> Ok.
> > 
> > > 
> > > Bspec: 69560
> > > Signed-off-by: Vinod Govindapillai
> > > <vinod.govindapillai@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_fbc.c | 9 ++++++++-
> > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > index 78228a5e765f..20f02ef9387a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > @@ -59,6 +59,7 @@
> > >  #include "intel_fbc_regs.h"
> > >  #include "intel_frontbuffer.h"
> > >  #include "intel_parent.h"
> > > +#include "skl_universal_plane.h"
> > >  
> > >  #define for_each_fbc_id(__display, __fbc_id) \
> > >  	for ((__fbc_id) = INTEL_FBC_A; (__fbc_id) <
> > > I915_MAX_FBCS;
> > > (__fbc_id)++) \
> > > @@ -1319,8 +1320,14 @@ static void intel_fbc_max_plane_size(const
> > > struct intel_plane_state *plane_state
> > >  				     unsigned int *w, unsigned
> > > int
> > > *h)
> > >  {
> > >  	struct intel_display *display =
> > > to_intel_display(plane_state);
> > > +	struct intel_plane *plane = to_intel_plane(plane_state-
> > > > uapi.plane);
> > > +	const struct drm_framebuffer *fb = plane_state->hw.fb;
> > > +	unsigned int rotation = plane_state->hw.rotation;
> > >  
> > > -	if (DISPLAY_VER(display) >= 10) {
> > > +	if (DISPLAY_VER(display) >= 20) {
> > > +		*w = intel_plane_max_width(plane, fb, 0,
> > > rotation);
> > > +		*h = 4096;
> > 
> > Bspec says 4088.
> 
> Yeah. I had the same question. According to HAS, these lines limits
> exists because of number of bits allocated to a factor tracked by the
> hw. 
> 
> And why I kept, the lines as 4096, because of the history of that
> value
> being used in other platforms even though bspec has 4088. This
> specific
> patch is mainly about the horizontal size, FBC can now support up to
> the maximum width a platform supports. The vertical lines restriction
> still holds as in the previous platforms. Historically it has been
> set
> at 4096 in the driver. So I didn't want to change that. My
> assumption,
> why it was kept like that in the driver could be that, this is the
> lines FBC can compress, beyond that lines wont be compressed but

well-- I just noticed a mistake in my response... FBC can compress only
2560 lines. Beyond that lines remain uncompressed but FBC is still
useful for width*2560 part.

> still
> FBC is useful. Otherwise we might be refusing to enable FBC in
> commonly
> used modes. Basically I just stick to the historic value being used.
> 
> BR
> Vinod 
> 
> > 
> > BR,
> > Jouni Högander
> > 
> > > +	} else if (DISPLAY_VER(display) >= 10) {
> > >  		*w = 5120;
> > >  		*h = 4096;
> > >  	} else if (DISPLAY_VER(display) >= 8 || display-
> > > > platform.haswell) {
> > 
> 


  reply	other threads:[~2026-07-21 11:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16 22:59 'From 351218ae36a91f36924c9b3c1ecc4d42100fd573 Mon Sep 17 00:00:00 2001 Vinod Govindapillai
2026-07-16 22:59 ` [PATCH 1/4] drm/xe/display: Expose plane max width/height helpers to global scope Vinod Govindapillai
2026-07-21  9:07   ` Hogander, Jouni
2026-07-16 22:59 ` [PATCH 2/4] drm/i915/fbc: refactor maximum plane size handling for fbc Vinod Govindapillai
2026-07-21  9:09   ` Hogander, Jouni
2026-07-21  9:48     ` Govindapillai, Vinod
2026-07-16 22:59 ` [PATCH 3/4] drm/i915/fbc: xe2_lpd+ don't require any hardcoded plane width limit Vinod Govindapillai
2026-07-21  9:01   ` Hogander, Jouni
2026-07-21  9:47     ` Govindapillai, Vinod
2026-07-21 11:00       ` Govindapillai, Vinod [this message]
2026-07-16 22:59 ` [PATCH 4/4] drm/i915/fbc: xe2_lpd+ no more surface size restrictions for FBC Vinod Govindapillai
2026-07-21  9:04   ` Hogander, Jouni
2026-07-16 23:06 ` ✗ CI.checkpatch: warning for series starting with [1/4] drm/xe/display: Expose plane max width/height helpers to global scope Patchwork
2026-07-16 23:07 ` ✓ CI.KUnit: success " Patchwork
2026-07-16 23:53 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-17  4:46 ` ✓ Xe.CI.FULL: " 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=38582f7a3e9032a64dc9cdffec5331c84098e4ca.camel@intel.com \
    --to=vinod.govindapillai@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jouni.hogander@intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox