From: "G, Pallavi" <pallavi.g@intel.com>
To: "Roper, Matthew D" <matthew.d.roper@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/6] drm: Refactor framebuffer creation to allow internal use (v2)
Date: Thu, 12 Jun 2014 09:02:06 +0000 [thread overview]
Message-ID: <1402564397.1130.3.camel@pg3-desktop> (raw)
In-Reply-To: <1402414093-13401-2-git-send-email-matthew.d.roper@intel.com>
On Tue, 2014-06-10 at 08:28 -0700, Matt Roper wrote:
> Refactor DRM framebuffer creation into a new function that returns a
> struct drm_framebuffer directly. The upcoming universal cursor support
> will want to create framebuffers internally to wrap cursor buffers, so
> we want to be able to share that framebuffer creation with the
> drm_mode_addfb2 ioctl handler.
>
> v2: Take struct drm_mode_fb_cmd2 parameter directly rather than void*
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> ---
> drivers/gpu/drm/drm_crtc.c | 69 ++++++++++++++++++++++++++++------------------
> 1 file changed, 42 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fe94cc1..5a88267 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -41,6 +41,10 @@
>
> #include "drm_crtc_internal.h"
>
> +static struct drm_framebuffer *add_framebuffer_internal(struct drm_device *dev,
> + struct drm_mode_fb_cmd2 *r,
> + struct drm_file *file_priv);
> +
> /**
> * drm_modeset_lock_all - take all modeset locks
> * @dev: drm device
> @@ -2827,56 +2831,38 @@ static int framebuffer_check(const struct drm_mode_fb_cmd2 *r)
> return 0;
> }
>
> -/**
> - * drm_mode_addfb2 - add an FB to the graphics configuration
> - * @dev: drm device for the ioctl
> - * @data: data pointer for the ioctl
> - * @file_priv: drm file for the ioctl call
> - *
> - * Add a new FB to the specified CRTC, given a user request with format. This is
> - * the 2nd version of the addfb ioctl, which supports multi-planar framebuffers
> - * and uses fourcc codes as pixel format specifiers.
> - *
> - * Called by the user via ioctl.
> - *
> - * Returns:
> - * Zero on success, errno on failure.
> - */
> -int drm_mode_addfb2(struct drm_device *dev,
> - void *data, struct drm_file *file_priv)
> +static struct drm_framebuffer *add_framebuffer_internal(struct drm_device *dev,
> + struct drm_mode_fb_cmd2 *r,
> + struct drm_file *file_priv)
> {
> - struct drm_mode_fb_cmd2 *r = data;
> struct drm_mode_config *config = &dev->mode_config;
> struct drm_framebuffer *fb;
> int ret;
>
> - if (!drm_core_check_feature(dev, DRIVER_MODESET))
> - return -EINVAL;
> -
> if (r->flags & ~DRM_MODE_FB_INTERLACED) {
> DRM_DEBUG_KMS("bad framebuffer flags 0x%08x\n", r->flags);
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
> }
>
> if ((config->min_width > r->width) || (r->width > config->max_width)) {
> DRM_DEBUG_KMS("bad framebuffer width %d, should be >= %d && <= %d\n",
> r->width, config->min_width, config->max_width);
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
> }
> if ((config->min_height > r->height) || (r->height > config->max_height)) {
> DRM_DEBUG_KMS("bad framebuffer height %d, should be >= %d && <= %d\n",
> r->height, config->min_height, config->max_height);
> - return -EINVAL;
> + return ERR_PTR(-EINVAL);
> }
>
> ret = framebuffer_check(r);
> if (ret)
> - return ret;
> + return ERR_PTR(ret);
>
> fb = dev->mode_config.funcs->fb_create(dev, file_priv, r);
> if (IS_ERR(fb)) {
> DRM_DEBUG_KMS("could not create framebuffer\n");
> - return PTR_ERR(fb);
> + return fb;
> }
>
> mutex_lock(&file_priv->fbs_lock);
> @@ -2885,8 +2871,37 @@ int drm_mode_addfb2(struct drm_device *dev,
> DRM_DEBUG_KMS("[FB:%d]\n", fb->base.id);
> mutex_unlock(&file_priv->fbs_lock);
>
> + return fb;
> +}
>
> - return ret;
> +/**
> + * drm_mode_addfb2 - add an FB to the graphics configuration
> + * @dev: drm device for the ioctl
> + * @data: data pointer for the ioctl
> + * @file_priv: drm file for the ioctl call
> + *
> + * Add a new FB to the specified CRTC, given a user request with format. This is
> + * the 2nd version of the addfb ioctl, which supports multi-planar framebuffers
> + * and uses fourcc codes as pixel format specifiers.
> + *
> + * Called by the user via ioctl.
> + *
> + * Returns:
> + * Zero on success, errno on failure.
> + */
> +int drm_mode_addfb2(struct drm_device *dev,
> + void *data, struct drm_file *file_priv)
> +{
> + struct drm_framebuffer *fb;
> +
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EINVAL;
> +
> + fb = add_framebuffer_internal(dev, data, file_priv);
> + if (IS_ERR(fb))
> + return PTR_ERR(fb);
> +
> + return 0;
> }
>
> /**
Reviewed-by: Pallavi G<pallavi.g@intel.com>
next prev parent reply other threads:[~2014-06-12 9:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 15:28 [PATCH 0/6] Cursor support with universal planes (v4) Matt Roper
2014-06-10 15:28 ` [PATCH 1/6] drm: Refactor framebuffer creation to allow internal use (v2) Matt Roper
2014-06-12 9:02 ` G, Pallavi [this message]
2014-06-10 15:28 ` [PATCH 2/6] drm: Refactor setplane to allow internal use (v3) Matt Roper
2014-06-12 9:05 ` G, Pallavi
2014-06-10 15:28 ` [PATCH 3/6] drm: Support legacy cursor ioctls via universal planes when possible (v4) Matt Roper
2014-06-12 9:06 ` G, Pallavi
2014-06-10 15:28 ` [PATCH 4/6] drm: Allow drivers to register cursor planes with crtc Matt Roper
2014-06-12 9:08 ` G, Pallavi
2014-06-10 15:28 ` [PATCH 5/6] drm/i915: Add intel_crtc_cursor_set_obj() to set cursor buffer (v2) Matt Roper
2014-06-12 9:44 ` G, Pallavi
2014-06-10 15:28 ` [PATCH 6/6] drm/i915: Switch to unified plane cursor handling (v4) Matt Roper
2014-06-12 11:47 ` G, Pallavi
2014-06-12 14:57 ` Matt Roper
2014-06-13 4:35 ` G, Pallavi
2014-06-13 6:46 ` Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2014-05-19 23:58 [PATCH 0/6] Cursor support with universal planes (v3) Matt Roper
2014-05-19 23:58 ` [PATCH 1/6] drm: Refactor framebuffer creation to allow internal use (v2) Matt Roper
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=1402564397.1130.3.camel@pg3-desktop \
--to=pallavi.g@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.d.roper@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.