From: Thierry Reding <thierry.reding@gmail.com>
To: Daniel Stone <daniels@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer
Date: Thu, 17 May 2018 16:46:37 +0200 [thread overview]
Message-ID: <20180517144637.GE26515@ulmo> (raw)
In-Reply-To: <20180330141138.28987-5-daniels@collabora.com>
[-- Attachment #1.1: Type: text/plain, Size: 3604 bytes --]
On Fri, Mar 30, 2018 at 03:11:19PM +0100, Daniel Stone wrote:
> Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
> can remove it.
>
> Signed-off-by: Daniel Stone <daniels@collabora.com>
> Cc: Sandy Huang <hjc@rock-chips.com>
> Cc: Heiko Stübner <heiko@sntech.de>
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 54 ++++++++++-------------------
> drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 3 --
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +--
> 3 files changed, 21 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> index d7083c07c294..a4d0a00abcd9 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> @@ -25,21 +25,6 @@
> #include "rockchip_drm_gem.h"
> #include "rockchip_drm_psr.h"
>
> -#define to_rockchip_fb(x) container_of(x, struct rockchip_drm_fb, fb)
> -
> -struct rockchip_drm_fb {
> - struct drm_framebuffer fb;
> -};
> -
> -struct drm_gem_object *rockchip_fb_get_gem_obj(struct drm_framebuffer *fb,
> - unsigned int plane)
> -{
> - if (plane >= ROCKCHIP_MAX_FB_BUFFER)
> - return NULL;
> -
> - return fb->obj[plane];
> -}
> -
> static int rockchip_drm_fb_dirty(struct drm_framebuffer *fb,
> struct drm_file *file,
> unsigned int flags, unsigned int color,
> @@ -56,41 +41,40 @@ static const struct drm_framebuffer_funcs rockchip_drm_fb_funcs = {
> .dirty = rockchip_drm_fb_dirty,
> };
>
> -static struct rockchip_drm_fb *
> +static struct drm_framebuffer *
> rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 *mode_cmd,
> struct drm_gem_object **obj, unsigned int num_planes)
> {
> - struct rockchip_drm_fb *rockchip_fb;
> + struct drm_framebuffer *fb;
> int ret;
> int i;
>
> - rockchip_fb = kzalloc(sizeof(*rockchip_fb), GFP_KERNEL);
> - if (!rockchip_fb)
> + fb = kzalloc(sizeof(*fb), GFP_KERNEL);
> + if (!fb)
> return ERR_PTR(-ENOMEM);
>
> - drm_helper_mode_fill_fb_struct(dev, &rockchip_fb->fb, mode_cmd);
> + drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
>
> for (i = 0; i < num_planes; i++)
> - rockchip_fb->fb.obj[i] = obj[i];
> + fb->obj[i] = obj[i];
>
> - ret = drm_framebuffer_init(dev, &rockchip_fb->fb,
> - &rockchip_drm_fb_funcs);
> + ret = drm_framebuffer_init(dev, fb, &rockchip_drm_fb_funcs);
> if (ret) {
> DRM_DEV_ERROR(dev->dev,
> "Failed to initialize framebuffer: %d\n",
> ret);
> - kfree(rockchip_fb);
> + kfree(fb);
> return ERR_PTR(ret);
> }
>
> - return rockchip_fb;
> + return fb;
> }
>
> static struct drm_framebuffer *
> rockchip_user_fb_create(struct drm_device *dev, struct drm_file *file_priv,
> const struct drm_mode_fb_cmd2 *mode_cmd)
> {
> - struct rockchip_drm_fb *rockchip_fb;
> + struct drm_framebuffer *fb;
> struct drm_gem_object *objs[ROCKCHIP_MAX_FB_BUFFER];
The use of the ROCKCHIP_MAX_FB_BUFFER seems somewhat misguided here.
What if a given pixel format requires 4 planes? This function will just
silently ignore the last plane. Not sure that's a good idea. Currently I
don't know of any formats that require 4 planes, so this is probably not
an issue, but there's also no reason to limit this to anything less than
the 4 planes that's baked into the KMS ABI everywhere.
Anyway, just a random comment and it doesn't have anything to do with
this series, so:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-05-17 14:46 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-30 14:11 [PATCH 00/24] drm_framebuffer boilerplate removal Daniel Stone
2018-03-30 14:11 ` [PATCH 01/24] drm/cirrus: Place GEM BOs in drm_framebuffer Daniel Stone
2018-03-30 14:11 ` [PATCH 02/24] drm/cirrus: cirrus_framebuffer -> drm_framebuffer Daniel Stone
2018-05-17 14:25 ` Thierry Reding
2018-03-30 14:11 ` [PATCH 03/24] drm/virtio: Place GEM BOs in drm_framebuffer Daniel Stone
2018-05-17 14:29 ` Thierry Reding
2018-03-30 14:11 ` [PATCH 04/24] drm/rockchip: " Daniel Stone
2018-05-17 13:57 ` Sean Paul
2018-05-17 14:47 ` Thierry Reding
2018-03-30 14:11 ` [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer Daniel Stone
2018-05-17 13:08 ` Daniel Stone
2018-05-17 13:42 ` Heiko Stübner
2018-05-17 14:09 ` Daniel Stone
2018-05-17 13:56 ` Sean Paul
2018-05-17 14:46 ` Thierry Reding [this message]
2018-03-30 14:11 ` [PATCH 06/24] drm/omap: Move GEM BO to drm_framebuffer Daniel Stone
2018-03-30 20:54 ` Sebastian Reichel
2018-05-17 14:47 ` Thierry Reding
2018-03-30 14:11 ` [PATCH 07/24] drm/omap: Move buffer pitch/offset " Daniel Stone
2018-03-30 20:53 ` Sebastian Reichel
2018-05-17 13:13 ` Daniel Stone
2018-05-17 14:49 ` Thierry Reding
2018-03-30 14:11 ` [PATCH 08/24] drm/mtk: Promote impossible internal error to WARN_ON Daniel Stone
2018-05-17 13:58 ` Sean Paul
2018-05-17 14:55 ` Thierry Reding
2018-05-18 8:06 ` CK Hu
2018-03-30 14:11 ` [PATCH 09/24] drm/mtk: Move GEM BO to drm_framebuffer Daniel Stone
2018-05-17 13:59 ` Sean Paul
2018-05-17 14:55 ` Thierry Reding
2018-05-18 8:32 ` CK Hu
2018-03-30 14:11 ` [PATCH 10/24] drm/mtk: mtk_drm_fb -> drm_framebuffer Daniel Stone
2018-05-17 13:13 ` Daniel Stone
2018-05-17 13:59 ` Sean Paul
2018-05-17 14:56 ` Thierry Reding
2018-05-18 8:37 ` CK Hu
2018-03-30 14:11 ` [PATCH 11/24] drm/tegra: Remove duplicate framebuffer num_planes Daniel Stone
2018-03-30 14:11 ` [PATCH 12/24] drm/tegra: Move GEM BOs to drm_framebuffer Daniel Stone
2018-03-30 14:11 ` [PATCH 13/24] drm/tegra: tegra_fb -> drm_framebuffer Daniel Stone
2018-05-17 13:11 ` Daniel Stone
2018-05-17 13:46 ` Thierry Reding
2018-03-30 14:11 ` [PATCH 14/24] drm/tegra: Move fbdev unmap special case Daniel Stone
2018-03-30 14:11 ` [PATCH 15/24] drm/tegra: Use drm_gem_fb_destroy Daniel Stone
2018-03-30 14:11 ` [PATCH 16/24] drm/exynos: Move GEM BOs to drm_framebuffer Daniel Stone
2018-04-13 8:55 ` Inki Dae
2018-04-13 10:13 ` Daniel Stone
2018-03-30 14:11 ` [PATCH 17/24] drm/exynos: Move dma_addr out of exynos_drm_fb Daniel Stone
2018-03-30 14:11 ` [PATCH 18/24] drm/exynos: exynos_drm_fb -> drm_framebuffer Daniel Stone
2018-03-30 14:11 ` [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer Daniel Stone
2018-05-17 13:15 ` Daniel Stone
2018-05-17 15:26 ` Russell King - ARM Linux
2018-05-17 15:41 ` Daniel Stone
2018-06-26 14:49 ` Russell King - ARM Linux
2018-06-27 10:40 ` Daniel Stone
2018-05-17 14:57 ` Thierry Reding
2018-03-30 14:11 ` [PATCH 20/24] drm/gma500: " Daniel Stone
2018-05-17 15:03 ` Thierry Reding
2018-03-30 14:11 ` [PATCH 21/24] drm/msm: Move GEM BOs " Daniel Stone
2018-05-17 13:12 ` Daniel Stone
2018-05-17 15:05 ` Thierry Reding
2018-03-30 14:11 ` [PATCH 22/24] drm/radeon: Move GEM BO " Daniel Stone
[not found] ` <20180330141138.28987-22-daniels-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2018-05-17 15:06 ` Thierry Reding
[not found] ` <20180330141138.28987-1-daniels-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
2018-03-30 14:11 ` [PATCH 23/24] drm/radeon: radeon_framebuffer -> drm_framebuffer Daniel Stone
2018-05-17 15:07 ` Thierry Reding
2018-03-30 14:11 ` [PATCH 24/24] drm/amdgpu: Move GEM BO to drm_framebuffer Daniel Stone
2018-05-17 15:08 ` Thierry Reding
2018-05-17 13:54 ` [PATCH 01/24] drm/cirrus: Place GEM BOs in drm_framebuffer Thierry Reding
2018-03-30 14:47 ` [PATCH 00/24] drm_framebuffer boilerplate removal Alex Deucher
2018-03-30 15:00 ` Daniel Stone
[not found] ` <CAPj87rOfg18u1xBioeu1D0MoD4My2rZy1Nw3yfA4DhdX2R7g7w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-03-30 15:03 ` Alex Deucher
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=20180517144637.GE26515@ulmo \
--to=thierry.reding@gmail.com \
--cc=daniels@collabora.com \
--cc=dri-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).