Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev
From: Maxime Ripard
Date: Wed Feb 22 2017 - 19:49:19 EST
On Mon, Feb 20, 2017 at 06:07:10PM +0100, Stefan Lengfeld wrote:
> 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
> On Wed, Feb 15, 2017 at 05:19:08PM +0100, Maxime Ripard wrote:
> > From: Xinliang Liu <xinliang.liu@xxxxxxxxxx>
> 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.
I don't usually know when to do that as well. But yeah, you're
> > 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@xxxxxxxxxx>
> > [s.christ@xxxxxxxxx: Picking patch from
> > https://lkml.org/lkml/2015/9/14/188]
> > Signed-off-by: Stefan Christ <s.christ@xxxxxxxxx>
> > Signed-off-by: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx>
> Reviewed-by: Stefan Lengfeld <contact@xxxxxxxxxxxxxxx>
> 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.
Yep, I'll change it.
> > +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.
That's a really good point, I'll change that.
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
Description: PGP signature