public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Eric Anholt <eric@anholt.net>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] drm: Trust format_mod_supported() when it OKs a plane modifier.
Date: Mon, 19 Mar 2018 18:33:33 +0200	[thread overview]
Message-ID: <20180319163333.GO5453@intel.com> (raw)
In-Reply-To: <20180316220435.31416-1-eric@anholt.net>

On Fri, Mar 16, 2018 at 03:04:33PM -0700, Eric Anholt wrote:
> For parameterized modifiers (Broadcom's SAND and UIF), we need to
> allow the parameter fields to be filled in, while exposing only the
> variant of the modifier with the parameter unfilled in the internal
> arrays and the format blob.
> 
> Signed-off-by: Eric Anholt <eric@anholt.net>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/drm_plane.c | 23 ++++++++++++-----------
>  include/drm/drm_plane.h     |  5 ++++-
>  2 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 46fbd019a337..5bb501f1aae8 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -561,19 +561,20 @@ int drm_plane_check_pixel_format(struct drm_plane *plane,
>  	if (i == plane->format_count)
>  		return -EINVAL;
>  
> -	if (!plane->modifier_count)
> -		return 0;
> +	if (plane->funcs->format_mod_supported) {
> +		if (!plane->funcs->format_mod_supported(plane, format, modifier))
> +			return -EINVAL;
> +	} else {
> +		if (!plane->modifier_count)
> +			return 0;
>  
> -	for (i = 0; i < plane->modifier_count; i++) {
> -		if (modifier == plane->modifiers[i])
> -			break;
> +		for (i = 0; i < plane->modifier_count; i++) {
> +			if (modifier == plane->modifiers[i])
> +				break;
> +		}
> +		if (i == plane->modifier_count)
> +			return -EINVAL;
>  	}
> -	if (i == plane->modifier_count)
> -		return -EINVAL;
> -
> -	if (plane->funcs->format_mod_supported &&
> -	    !plane->funcs->format_mod_supported(plane, format, modifier))
> -		return -EINVAL;
>  
>  	return 0;
>  }
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index f7bf4a48b1c3..6b1b51645f75 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -420,7 +420,10 @@ struct drm_plane_funcs {
>  	 * This optional hook is used for the DRM to determine if the given
>  	 * format/modifier combination is valid for the plane. This allows the
>  	 * DRM to generate the correct format bitmask (which formats apply to
> -	 * which modifier).
> +	 * which modifier), and to valdiate modifiers at atomic_check time.
> +	 *
> +	 * If not present, then any modifier in the plane's modifier
> +	 * list is allowed with any of the plane's formats.

This certainly avoids the vfunc profileration that using the
modifiers list causes. So yeah I do like it from that angle.

It does promote .format_mod_supported() to a more prominent role. My
original idea for .format_mod_supported() was that it could be very
lightweight; just reject the exceptional cases and assume everything
else is fine. With the change of role I think the docs should make it
very clear that _any_ modifier can be passed to this function directly
from userspace. The driver must handle that gracefully and without
spewing any non-debug stuff to dmesg.

Also I definitely need to change i915. Currently we're using the
modifier list as the primary means by which we filter out unsupported
modifiers for planes, and .format_mod_support() just serves an
supporting role further removing any format+mod combination that isn't
valid. So I need to make .format_mod_supported() the lead actor here
and the modifier list just serves as a starting point which we filter
down to something we can report via the IN_FORMATS blobifier.

Hmm. And now the question becomes should we make .format_mod_supported()
take over the role of validating the pixel format as well from the
plane's format list? It would certainly be more in line with the
approach we're now going to take with modifiers.

-- 
Ville Syrjälä
Intel OTC

  parent reply	other threads:[~2018-03-19 16:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-16 22:04 [PATCH 1/3] drm: Trust format_mod_supported() when it OKs a plane modifier Eric Anholt
2018-03-16 22:04 ` [PATCH 2/3] drm/vc4: Add missing formats to vc4_format_mod_supported() Eric Anholt
2018-03-16 22:04 ` [PATCH 3/3] drm/vc4: Add support for SAND modifier Eric Anholt
2018-03-19 16:33 ` Ville Syrjälä [this message]
2018-05-22 16:31 ` [PATCH 1/3] drm: Trust format_mod_supported() when it OKs a plane modifier Ville Syrjälä

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=20180319163333.GO5453@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@anholt.net \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox