All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/7] drm/i915/fbc: Eliminate possible_framebuffer_bits
Date: Tue, 15 Mar 2022 16:49:24 +0200	[thread overview]
Message-ID: <87pmmntgnf.fsf@intel.com> (raw)
In-Reply-To: <20220315140001.1172-2-ville.syrjala@linux.intel.com>

On Tue, 15 Mar 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Not sure what the point of this fbc->possible_frontbuffer_bits is.
> And especially don't see why it's returning all the bits when
> fbc is not even enabled. So let's just get rid of this and only
> say we are interested in the plane's frontbuffer bits when fbc
> is actually enabled.

So, uh, why are we calling this "bits", all over the place? It doesn't
tell anything to a casual reader. It's been percolated to fbc, psr,
plane, frontbuffer...

It's a kind of slot or id mask? I think the naming should reflect that,
and it would be easier to read. For future cleanup.

For the patch at hand, beats me,

Acked-by: Jani Nikula <jani.nikula@intel.com>

>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> ---
>drivers/gpu/drm/i915/display/intel_fbc.c | 7 +------ 1 file changed, 1
>insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 142280b6ce6d..e45d64655090 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -89,7 +89,6 @@ struct intel_fbc {
>  	 * with stolen_lock.
>  	 */
>  	struct mutex lock;
> -	unsigned int possible_framebuffer_bits;
>  	unsigned int busy_bits;
>  
>  	struct drm_mm_node compressed_fb;
> @@ -1316,7 +1315,7 @@ static unsigned int intel_fbc_get_frontbuffer_bit(struct intel_fbc *fbc)
>  	if (fbc->state.plane)
>  		return fbc->state.plane->frontbuffer_bit;
>  	else
> -		return fbc->possible_framebuffer_bits;
> +		return 0;
>  }
>  
>  static void __intel_fbc_invalidate(struct intel_fbc *fbc,
> @@ -1655,11 +1654,7 @@ static bool need_fbc_vtd_wa(struct drm_i915_private *i915)
>  
>  void intel_fbc_add_plane(struct intel_fbc *fbc, struct intel_plane *plane)
>  {
> -	if (!fbc)
> -		return;
> -
>  	plane->fbc = fbc;
> -	fbc->possible_framebuffer_bits |= plane->frontbuffer_bit;
>  }
>  
>  static struct intel_fbc *intel_fbc_create(struct drm_i915_private *i915,

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-03-15 14:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15 13:59 [Intel-gfx] [PATCH 0/7] drm/i915/fbc: FBC frontbuffer stuff Ville Syrjala
2022-03-15 13:59 ` [Intel-gfx] [PATCH 1/7] drm/i915/fbc: Eliminate possible_framebuffer_bits Ville Syrjala
2022-03-15 14:49   ` Jani Nikula [this message]
2022-03-15 13:59 ` [Intel-gfx] [PATCH 2/7] drm/i915/fbc: Streamline frontbuffer busy bits handling Ville Syrjala
2022-03-15 13:59 ` [Intel-gfx] [PATCH 3/7] drm/i915/fbc: Skip nuke when flip is pending Ville Syrjala
2022-03-15 13:59 ` [Intel-gfx] [PATCH 4/7] drm/i915: Remove remaining locks from i9xx plane udpates Ville Syrjala
2022-03-15 13:59 ` [Intel-gfx] [PATCH 5/7] drm/i915/fbc: Remove intel_fbc_global_disable() Ville Syrjala
2022-03-15 14:00 ` [Intel-gfx] [PATCH 6/7] drm/i915/fbc: Introduce intel_fbc_sanitize() Ville Syrjala
2022-03-15 14:00 ` [Intel-gfx] [PATCH 7/7] drm/i915/fbc: Call intel_fbc_activate() directly from frontbuffer flush Ville Syrjala
2022-03-15 14:46 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/fbc: FBC frontbuffer stuff Patchwork
2022-03-15 15:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-15 17:24 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-04-13 13:51 ` [Intel-gfx] [PATCH 0/7] " Kahola, Mika

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=87pmmntgnf.fsf@intel.com \
    --to=jani.nikula@linux.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.