All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Use enum plane_id for frontbuffer tracking
Date: Wed, 24 Jan 2018 19:36:01 +0200	[thread overview]
Message-ID: <20180124173601.GV5453@intel.com> (raw)
In-Reply-To: <151674188370.13096.15919539242730425189@mail.alporthouse.com>

On Tue, Jan 23, 2018 at 09:11:23PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-01-23 18:33:43)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Replace the ad-hoc plane indexing scheme used by the frontbuffer
> > tracking with enum plane_id.
> > 
> > The old video overlay not being part of the plane_id namespace
> > will just be given the high bit.
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h      | 11 +++--------
> >  drivers/gpu/drm/i915/intel_display.c |  4 ++--
> >  drivers/gpu/drm/i915/intel_fbc.c     |  2 +-
> >  drivers/gpu/drm/i915/intel_sprite.c  |  4 +++-
> >  4 files changed, 9 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index 8333692dac5a..bd545b1c9546 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2404,16 +2404,11 @@ enum hdmi_force_audio {
> >   *
> >   * We have one bit per pipe and per scanout plane type.
> >   */
> > -#define INTEL_MAX_SPRITE_BITS_PER_PIPE 5
> >  #define INTEL_FRONTBUFFER_BITS_PER_PIPE 8
> 
> I would feel safer with a BUILD_BUG_ON to catch plane_id overflowing
> INTEL_FRONTBUFFER_BITS_PER_PIPE (-1 for the overlay reservation).

Actaully we'll be going past that BITS_PER_PIPE-1 limit real soon
now, but the BITS_PER_PIPE will be sufficient for some time I think.
So I think I'd just rather ignore the overlap between the plane_id
and the overlay because that's not going happen on actual hardware.

But I think asserting that BITS_PER_PIPE is sufficient is a good idea.
Just need to figure out where to put it. There's no init function
or anything like that in the frontbuffer tracking code, so that's
not going to work. I guess one option would be to include the
assert in the INTEL_FRONTBUFFER() macro itself.

> 
> > -#define INTEL_FRONTBUFFER_PRIMARY(pipe) \
> > -       (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > -#define INTEL_FRONTBUFFER_CURSOR(pipe) \
> > -       (1 << (1 + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))))
> > -#define INTEL_FRONTBUFFER_SPRITE(pipe, plane) \
> > -       (1 << (2 + plane + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))))
> > +#define INTEL_FRONTBUFFER(pipe, plane_id) \
> > +       (1 << ((plane_id) + INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> >  #define INTEL_FRONTBUFFER_OVERLAY(pipe) \
> > -       (1 << (2 + INTEL_MAX_SPRITE_BITS_PER_PIPE + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))))
> > +       (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE - 1 + INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> >  #define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
> >         (0xff << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> 
> The conversion looks straightforward nevertheless, and indeed no reason
> to have move than one indexing id for a plane.
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-01-24 17:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23 18:33 [PATCH] drm/i915: Use enum plane_id for frontbuffer tracking Ville Syrjala
2018-01-23 19:00 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-01-23 21:11 ` [PATCH] " Chris Wilson
2018-01-24 17:36   ` Ville Syrjälä [this message]
2018-01-24 18:19     ` Ville Syrjälä
2018-01-23 21:12 ` Chris Wilson
2018-01-24  4:04 ` ✗ Fi.CI.IGT: failure for " Patchwork
2018-01-24 17:09   ` Ville Syrjälä
2018-01-24  4:16 ` [PATCH] " Pandiyan, Dhinakaran
2018-01-24 15:16   ` Ville Syrjälä
2018-01-24 19:03     ` Pandiyan, Dhinakaran

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=20180124173601.GV5453@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.