All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Eric Anholt <eric@anholt.net>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/i915: Promote .format_mod_supported() to the lead role
Date: Wed, 30 May 2018 23:10:10 +0300	[thread overview]
Message-ID: <20180530201010.GT23723@intel.com> (raw)
In-Reply-To: <87r2lthu7x.fsf@anholt.net>

On Wed, May 30, 2018 at 11:30:26AM -0700, Eric Anholt wrote:
> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> 
> > On Mon, May 21, 2018 at 12:21:01PM -0700, Eric Anholt wrote:
> >> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
> >> 
> >> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >
> >> > Up to now we've used the plane's modifier list as the primary
> >> > source of information for which modifiers are supported by a
> >> > given plane. In order to allow auxiliary metadata to be embedded
> >> > within the bits of the modifier we need to stop doing that.
> >> >
> >> > Thus we have to make .format_mod_supported() aware of the plane's
> >> > capabilities and gracefully deal with any modifier being passed
> >> > in directly from userspace.
> >> 
> >> This seems like it would be a lot shorter if you just had a helper to
> >> check if your format and modifier was in drm_plane->format_types and
> >> drm_plane->modifiers, since then you wouldn't be duplicating your tables
> >> and you wouldn't need has_ccs either.
> >
> > I suppose. And I guess that's where I started originally :/
> >
> > But I'm not sure if it's better go that route or the other route of
> > reducing the arrays to some simple supersets and also utilize
> > .format_mod_supported() in plane init to filter out the unsupported
> > formats when populating the plane's format list. Probably best not
> > dwell on this too much for now so that we can at least make some
> > progress :)
> >
> >> 
> >> However, it's not my driver and it unblocks vc4's patch, so:
> >> 
> >> Reviewed-by: Eric Anholt <eric@anholt.net>
> >
> > Thanks. I'm guessing we should push this into drm-misc-next so
> > that you can pile your core/sand bits on top?
> 
> That would be wonderful.

Now pushed. Had to resolve a few nv12 conflicts each way. I guess
someone else will get to deal with that same fun at some point

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

  reply	other threads:[~2018-05-30 20:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19 16:50 [PATCH] drm/i915: Promote .format_mod_supported() to the lead role Ville Syrjala
2018-03-19 18:16 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-03-19 18:31 ` ✓ Fi.CI.BAT: success " Patchwork
2018-03-19 21:17 ` ✗ Fi.CI.IGT: warning " Patchwork
2018-03-19 21:23   ` Ville Syrjälä
2018-03-30 19:06 ` [PATCH] " Eric Anholt
2018-04-27 16:33   ` Ville Syrjälä
2018-05-18 16:21 ` [PATCH v2] " Ville Syrjala
2018-05-21 19:21   ` Eric Anholt
2018-05-22 16:36     ` Ville Syrjälä
2018-05-30 18:30       ` Eric Anholt
2018-05-30 20:10         ` Ville Syrjälä [this message]
2018-05-18 16:33 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Promote .format_mod_supported() to the lead role (rev2) Patchwork
2018-05-18 16:48 ` ✓ Fi.CI.BAT: success " Patchwork
2018-05-19  0:49 ` ✓ Fi.CI.IGT: " 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=20180530201010.GT23723@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=eric@anholt.net \
    --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.