All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org,
	Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Subject: Re: [PATCH v4 1/2] drm: Add drm_any_plane_has_format()
Date: Mon, 29 Oct 2018 16:00:04 -0700	[thread overview]
Message-ID: <87tvl4s6iz.fsf@anholt.net> (raw)
In-Reply-To: <20181029183453.28541-1-ville.syrjala@linux.intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 1170 bytes --]

Ville Syrjala <ville.syrjala@linux.intel.com> writes:

> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Add a function to check whether there is at least one plane that
> supports a specific format and modifier combination. Drivers can
> use this to reject unsupported formats/modifiers in .fb_create().
>
> v2: Accept anyformat if the driver doesn't do planes (Eric)
>     s/planes_have_format/any_plane_has_format/ (Eric)
>     Check the modifier as well since we already have a function
>     that does both
> v3: Don't do the check in the core since we may not know the
>     modifier yet, instead export the function and let drivers
>     call it themselves
>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

I don't particularly see the point in having FB creation duplicate the
validation that atomic check will eventually do, and it means that FB
creation cost scales with plane count, but if i915's going to do this,
it seems reasonable for them.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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

  parent reply	other threads:[~2018-10-29 23:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-29 18:34 [PATCH v4 1/2] drm: Add drm_any_plane_has_format() Ville Syrjala
2018-10-29 18:34 ` [PATCH v4 2/2] drm/i915: Eliminate the horrendous format check code Ville Syrjala
2018-10-29 19:23   ` Dhinakaran Pandiyan
2018-10-29 20:48 ` ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm: Add drm_any_plane_has_format() Patchwork
2018-10-29 23:00 ` Eric Anholt [this message]
2018-10-30  9:35   ` [PATCH v4 1/2] " Daniel Vetter
2018-10-30 14:18     ` Ville Syrjälä
2018-10-30 15:35       ` Daniel Vetter
2018-10-30  1:48 ` ✓ Fi.CI.IGT: success for series starting with [v4,1/2] " 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=87tvl4s6iz.fsf@anholt.net \
    --to=eric@anholt.net \
    --cc=dhinakaran.pandiyan@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --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.