From: Stefan Lengfeld <contact@stefanchrist.eu>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
David Airlie <airlied@linux.ie>,
Sean Paul <seanpaul@chromium.org>,
Jani Nikula <jani.nikula@linux.intel.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev
Date: Mon, 20 Feb 2017 18:07:10 +0100 [thread overview]
Message-ID: <20170220170710.GA17643@sill.h.stcim.de> (raw)
In-Reply-To: <075ffb50cc16ab055b5d47b30163401bb356ab51.1487175046.git-series.maxime.ripard@free-electrons.com>
Hi Maxime,
sorry, I have missed the discussion about the double buffering/virtual
surface size patch series two weeks ago. My comments about the patch are
inline:
On Wed, Feb 15, 2017 at 05:19:08PM +0100, Maxime Ripard wrote:
> From: Xinliang Liu <xinliang.liu@linaro.org>
Mabye you should take the authorship here. Taking the credit and the
blame, because the patch was heavily modified by you and me. But I don't
really know what the offical police about that is.
>
> This patch add a config to support to create multi buffer for cma fbdev.
> Such as double buffer and triple buffer.
>
> Cma fbdev is convient to add a legency fbdev. And still many Android
> devices use fbdev now and at least double buffer is needed for these
> Android devices, so that a buffer flip can be operated. It will need
> some time for Android device vendors to abondon legency fbdev. So multi
> buffer for fbdev is needed.
>
> Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org>
> [s.christ@phytec.de: Picking patch from
> https://lkml.org/lkml/2015/9/14/188]
> Signed-off-by: Stefan Christ <s.christ@phytec.de>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Stefan Lengfeld <contact@stefanchrist.eu>
My surname has changed from "Christ" to "Lengfeld" recently. So my
review tag contains the new name.
> ---
> drivers/gpu/drm/Kconfig | 9 +++++++++
> drivers/gpu/drm/drm_fb_helper.c | 10 ++++++++++
> 2 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index ebfe8404c25f..700c8b8e57a9 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -84,6 +84,15 @@ config DRM_FBDEV_EMULATION
>
> If in doubt, say "Y".
>
> +config DRM_FBDEV_OVERALLOC
> + int "Overallocation of the fbdev buffer"
> + depends on DRM_FBDEV_EMULATION
> + default 100
> + help
> + Defines the fbdev buffer overallocation in percent. Default
> + is 100. Typical values for double buffering will be 200,
> + triple buffering 300.
> +
> config DRM_LOAD_EDID_FIRMWARE
> bool "Allow to specify an EDID data set instead of probing for it"
> depends on DRM_KMS_HELPER
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index e934b541feea..c6de87abaca8 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -48,6 +48,12 @@ module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600);
> MODULE_PARM_DESC(fbdev_emulation,
> "Enable legacy fbdev emulation [default=true]");
>
> +static int drm_fbdev_overalloc = CONFIG_DRM_FBDEV_OVERALLOC;
> +module_param(drm_fbdev_overalloc, int, 0444);
Maybe the variable should be of type "uint" instead of "int". This would
rule out the negative numbers error case.
> +MODULE_PARM_DESC(drm_fbdev_overalloc,
> + "Overallocation of the fbdev buffer (%) [default="
> + __MODULE_STRING(CONFIG_DRM_FBDEV_OVERALLOC) "]");
> +
> static LIST_HEAD(kernel_fb_helper_list);
> static DEFINE_MUTEX(kernel_fb_helper_lock);
>
> @@ -1573,6 +1579,10 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper,
> sizes.fb_height = sizes.surface_height = 768;
> }
>
> + /* Handle our overallocation */
> + sizes.surface_height *= drm_fbdev_overalloc;
> + sizes.surface_height /= 100;
> +
The code can trigger an arithmetic overflow, but I think we can ignore
this error case here.
But there should be a check for drm_fbdev_overalloc not be smaller than
100. If it is smaller, the variable drm_fbdev_overalloc should have the
default value "100". Otherwise the virtual surface height can be smaller
than the physical height. This could trigger a lot of errors in existing
code paths.
Kind regards,
Stefan Lengfeld
> /* push down into drivers */
> ret = (*fb_helper->funcs->fb_probe)(fb_helper, &sizes);
> if (ret < 0)
> --
> git-series 0.8.11
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-02-20 17:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 16:19 [PATCH v3 0/2] drm: Support framebuffer panning Maxime Ripard
2017-02-15 16:19 ` [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev Maxime Ripard
2017-02-20 17:07 ` Stefan Lengfeld [this message]
2017-02-23 0:49 ` Maxime Ripard
2017-02-26 21:06 ` Daniel Vetter
2017-02-15 16:19 ` [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC Maxime Ripard
2017-02-21 10:00 ` Stefan Lengfeld
2017-02-21 10:55 ` Ville Syrjälä
2017-02-23 0:52 ` Maxime Ripard
2017-02-23 9:02 ` Stefan Lengfeld
2017-02-26 21:11 ` Daniel Vetter
2017-02-22 7:05 ` Michel Dänzer
2017-02-16 16:40 ` [PATCH v3 0/2] drm: Support framebuffer panning Neil Armstrong
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=20170220170710.GA17643@sill.h.stcim.de \
--to=contact@stefanchrist.eu \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=seanpaul@chromium.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