All of lore.kernel.org
 help / color / mirror / Atom feed
From: Archit Taneja <architt@codeaurora.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 05/10] drm/doc: Polish for drm_plane.[hc]
Date: Fri, 2 Sep 2016 15:00:38 +0530	[thread overview]
Message-ID: <57C946BE.9040000@codeaurora.org> (raw)
In-Reply-To: <20160831160913.12991-6-daniel.vetter@ffwll.ch>



On 8/31/2016 9:39 PM, Daniel Vetter wrote:
> Big thing is untangling and carefully documenting the different uapi
> types of planes. I also sprinkled a few more cross references around
> to make this easier to discover.
>
> As usual, remove the kerneldoc for internal functions which are not
> exported. Aside: We should probably go OCD on all the ioctl handlers
> and consistenly give them an _ioctl postfix.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>   Documentation/gpu/drm-kms.rst |  47 +--------------
>   drivers/gpu/drm/drm_crtc.c    |   6 +-
>   drivers/gpu/drm/drm_plane.c   | 132 ++++++++----------------------------------
>   include/drm/drm_plane.h       |  57 +++++++++++++++++-
>   4 files changed, 86 insertions(+), 156 deletions(-)
>
<snip>

> +/**
> + * enum drm_plane_type - uapi plane type enumeration
> + *
> + * For historical reasons not all planes are made the same. This enumeration is
> + * used to tell the different types of planes apart to implement the different
> + * uapi semantics for them. For userspace which is universal plane aware and
> + * which is using that atomic IOCTL there's no difference between these planes
> + * (beyong what the driver and hardware can support of course).
> + *
> + * For compatibility with legacy userspace, only overlay planes are made
> + * available to userspace by default. Userspace clients may set the
> + * DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that they
> + * wish to receive a universal plane list containing all plane types. See also
> + * drm_for_each_legacy_plane().
> + */
>   enum drm_plane_type {
> -	DRM_PLANE_TYPE_OVERLAY,

Any reason why you moved this down? I guess there is no harm, but people
might be printing plane type while debugging, and they'd assume
DRM_PLANE_TYPE_OVERLAY=0

Thanks,
Archit

> +	/**
> +	 * @DRM_PLANE_TYPE_PRIMARY:
> +	 *
> +	 * Primary planes represent a "main" plane for a CRTC.  Primary planes
> +	 * are the planes operated upon by CRTC modesetting and flipping
> +	 * operations described in the page_flip and set_config hooks in struct
> +	 * &drm_crtc_funcs.
> +	 */
>   	DRM_PLANE_TYPE_PRIMARY,
> +
> +	/**
> +	 * @DRM_PLANE_TYPE_CURSOR:
> +	 *
> +	 * Cursor planes represent a "cursor" plane for a CRTC.  Cursor planes
> +	 * are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and
> +	 * DRM_IOCTL_MODE_CURSOR2 IOCTLs.
> +	 */
>   	DRM_PLANE_TYPE_CURSOR,
> +
> +	/**
> +	 * @DRM_PLANE_TYPE_OVERLAY:
> +	 *
> +	 * Overlay planes represent all non-primary, non-cursor planes. Some
> +	 * drivers refer to these types of planes as "sprites" internally.
> +	 */
> +	DRM_PLANE_TYPE_OVERLAY,
>   };
>
>
> @@ -458,11 +496,26 @@ static inline struct drm_plane *drm_plane_find(struct drm_device *dev,
>   	list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \
>   		for_each_if ((plane_mask) & (1 << drm_plane_index(plane)))
>
> -/* Plane list iterator for legacy (overlay only) planes. */
> +/**
> + * drm_for_each_legacy_plane - iterate over all planes for legacy userspace
> + * @plane: the loop cursor
> + * @dev: the DRM device
> + *
> + * Iterate over all legacy planes of @dev, excluding primary and cursor planes.
> + * This is useful for implementing userspace apis when userspace is not
> + * universal plane aware. See also enum &drm_plane_type.
> + */
>   #define drm_for_each_legacy_plane(plane, dev) \
>   	list_for_each_entry(plane, &(dev)->mode_config.plane_list, head) \
>   		for_each_if (plane->type == DRM_PLANE_TYPE_OVERLAY)
>
> +/**
> + * drm_for_each_plane - iterate over all planes
> + * @plane: the loop cursor
> + * @dev: the DRM device
> + *
> + * Iterate over all planes of @dev, include primary and cursor planes.
> + */
>   #define drm_for_each_plane(plane, dev) \
>   	list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)
>
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-09-02  9:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-31 16:09 [PATCH 00/10] More splitting&documenting for drm_crtc.c Daniel Vetter
2016-08-31 16:09 ` [PATCH 01/10] drm: Move a few macros away from drm_crtc.h Daniel Vetter
2016-09-06 16:59   ` [Intel-gfx] " Sean Paul
2016-09-08  0:05   ` Carlos Santa
2016-08-31 16:09 ` [PATCH 02/10] drm: Extract drm_bridge.h Daniel Vetter
2016-09-02  9:25   ` Archit Taneja
2016-08-31 16:09 ` [PATCH 03/10] drm: Move all decl for drm_edid.c to drm_edid.h Daniel Vetter
2016-09-06 16:59   ` Sean Paul
2016-09-19 14:28     ` Daniel Vetter
2016-08-31 16:09 ` [PATCH 04/10] drm: Extract drm_plane.[hc] Daniel Vetter
2016-09-06 16:59   ` [Intel-gfx] " Sean Paul
2016-09-19 13:11     ` Daniel Vetter
2016-09-21  7:32       ` Sean Paul
2016-08-31 16:09 ` [PATCH 05/10] drm/doc: Polish for drm_plane.[hc] Daniel Vetter
2016-09-02  9:30   ` Archit Taneja [this message]
2016-09-19 13:13     ` Daniel Vetter
2016-09-21  6:38       ` Archit Taneja
2016-08-31 16:09 ` [PATCH 06/10] drm: Conslidate blending properties in drm_blend.[hc] Daniel Vetter
2016-09-06 16:59   ` Sean Paul
2016-08-31 16:09 ` [PATCH 07/10] drm/doc: Polish plane composition property docs Daniel Vetter
2016-09-06 16:59   ` Sean Paul
2016-08-31 16:09 ` [PATCH 08/10] drm: Extract drm_color_mgmt.[hc] Daniel Vetter
2016-09-01  9:51   ` [Intel-gfx] " Lionel Landwerlin
2016-08-31 16:09 ` [PATCH 09/10] drm/doc: Document color space handling Daniel Vetter
2016-09-01 10:16   ` Lionel Landwerlin
2016-09-06 16:59   ` [Intel-gfx] " Sean Paul
2016-08-31 16:09 ` [PATCH 10/10] drm: Remove dirty property from docs Daniel Vetter
2016-09-06 16:59   ` Sean Paul
2016-09-01  9:20 ` ✗ Fi.CI.BAT: failure for More splitting&documenting for drm_crtc.c 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=57C946BE.9040000@codeaurora.org \
    --to=architt@codeaurora.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --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.