Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1581419 > unrolled thread

[PATCH v3 0/2] drm: Support framebuffer panning

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 0/2] drm: Support framebuffer panning Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-02-15 17:20 +0100
    [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-02-15 17:20 +0100
      Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma  fbdev Stefan Lengfeld <contact@stefanchrist.eu> - 2017-02-20 19:00 +0100
        Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma  fbdev Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-02-23 01:50 +0100
          Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma  fbdev Daniel Vetter <daniel@ffwll.ch> - 2017-02-26 22:10 +0100
    Re: [PATCH v3 0/2] drm: Support framebuffer panning Neil Armstrong <narmstrong@baylibre.com> - 2017-02-16 17:50 +0100

#1581419 — [PATCH v3 0/2] drm: Support framebuffer panning

Hi,

This is a respin of the previous serie called "Support fast framebuffer
panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been
removed, and the comments that were made at that time fixed (hopefully).

Let me know what you think,
Maxime

Changes from v2:
  - Renamed the CONFIG_DRM_CMA_FBDEV_BUFFER_NUM to
    CONFIG_DRM_FBDEV_OVERALLOC, and changed it for a percentage
  - Moved the overallocation code into the core fbdev helpers to not rely
    on CMA anymore
  - Changed the locks taken by drm_fb_helper_ioctl to the mode_config mutex
    intead of calling drm_modeset_lock_all
  - Don't test against drm_crtc's enabled anymore, but rely on the error
    code of drm_crtc_vblank_get instead
  - Defined drm_fb_helper_ioctl when DRM_FBDEV_EMULATION is not set in
    order to fix a compilation error
  - Don't wait for all CRTC's vblank but only the one given in the ioctl
    argument

Changes from v1:
  - Added drm_fb_helper_ioctl to DRM_FB_HELPER_DEFAULT_OPS
  - Expanded a bit the kerneldoc for drm_fb_helper_ioctl
  - Added some locking to drm_fb_helper_ioctl
  - Checked that the framebuffer is indeed attached before allowing ioctl
  - Added a module parameter to specify the number of framebuffers to
    allocate

Initial cover letter: Support fast framebuffer panning for i.MX6

im currently working on supporting double/tripple buffering for the
framebuffer emulation on the i.MX6.  While working on it I noticed that the
mainline kernel does not support some features in the generic drm
framebuffer emulation for framebuffer panning and vsync synchronisation.
They are needed for simple framebuffer applications and some OpenGL
libraries using double buffering with FBIOPUT_VSCREENINFO,
FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY.

Stefan Christ (1):
  drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

Xinliang Liu (1):
  drm/fb-helper: Add multi buffer support for cma fbdev

 drivers/gpu/drm/Kconfig         |  9 ++++-
 drivers/gpu/drm/drm_fb_helper.c | 73 ++++++++++++++++++++++++++++++++++-
 include/drm/drm_fb_helper.h     | 12 +++++-
 3 files changed, 93 insertions(+), 1 deletion(-)

base-commit: 0879b944c95d65f7523d178d3addaebe84e510ec
-- 
git-series 0.8.11

[toc] | [next] | [standalone]

#1581427 — [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev

From: Xinliang Liu <xinliang.liu@linaro.org>

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>
---
 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);
+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;
+
 	/* push down into drivers */
 	ret = (*fb_helper->funcs->fb_probe)(fb_helper, &sizes);
 	if (ret < 0)
-- 
git-series 0.8.11

[toc] | [prev] | [next] | [standalone]

#1584804 — Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev

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

[toc] | [prev] | [next] | [standalone]

#1586581 — Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev

[Multipart message — attachments visible in raw view] — view raw

Hi Stefan,

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
> 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.

I don't usually know when to do that as well. But yeah, you're
probably right.

> > 
> > 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.

Ack

> 
> > ---
> >  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.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1588397 — Re: [PATCH v3 1/2] drm/fb-helper: Add multi buffer support for cma fbdev

On Wed, Feb 22, 2017 at 04:49:01PM -0800, Maxime Ripard wrote:
> Hi Stefan,
> 
> 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
> > 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.
> 
> I don't usually know when to do that as well. But yeah, you're
> probably right.

Sob line is the important bit, retaining original authorship is just
goodwill, and if in doubt showing more curtesy rarely hurts :-)

Patch applied to drm-misc, with Dave's ack after a quick irc discussion.
-Daniel

> 
> > > 
> > > 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.
> 
> Ack
> 
> > 
> > > ---
> > >  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.
> 
> Thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com



> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1582699

On 02/15/2017 05:19 PM, Maxime Ripard wrote:
> Hi,
> 
> This is a respin of the previous serie called "Support fast framebuffer
> panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been
> removed, and the comments that were made at that time fixed (hopefully).
> 
> Let me know what you think,
> Maxime
> 
> Changes from v2:
>   - Renamed the CONFIG_DRM_CMA_FBDEV_BUFFER_NUM to
>     CONFIG_DRM_FBDEV_OVERALLOC, and changed it for a percentage
>   - Moved the overallocation code into the core fbdev helpers to not rely
>     on CMA anymore
>   - Changed the locks taken by drm_fb_helper_ioctl to the mode_config mutex
>     intead of calling drm_modeset_lock_all
>   - Don't test against drm_crtc's enabled anymore, but rely on the error
>     code of drm_crtc_vblank_get instead
>   - Defined drm_fb_helper_ioctl when DRM_FBDEV_EMULATION is not set in
>     order to fix a compilation error
>   - Don't wait for all CRTC's vblank but only the one given in the ioctl
>     argument
> 
> Changes from v1:
>   - Added drm_fb_helper_ioctl to DRM_FB_HELPER_DEFAULT_OPS
>   - Expanded a bit the kerneldoc for drm_fb_helper_ioctl
>   - Added some locking to drm_fb_helper_ioctl
>   - Checked that the framebuffer is indeed attached before allowing ioctl
>   - Added a module parameter to specify the number of framebuffers to
>     allocate
> 
> Initial cover letter: Support fast framebuffer panning for i.MX6
> 
> im currently working on supporting double/tripple buffering for the
> framebuffer emulation on the i.MX6.  While working on it I noticed that the
> mainline kernel does not support some features in the generic drm
> framebuffer emulation for framebuffer panning and vsync synchronisation.
> They are needed for simple framebuffer applications and some OpenGL
> libraries using double buffering with FBIOPUT_VSCREENINFO,
> FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY.
> 
> Stefan Christ (1):
>   drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC
> 
> Xinliang Liu (1):
>   drm/fb-helper: Add multi buffer support for cma fbdev
> 
>  drivers/gpu/drm/Kconfig         |  9 ++++-
>  drivers/gpu/drm/drm_fb_helper.c | 73 ++++++++++++++++++++++++++++++++++-
>  include/drm/drm_fb_helper.h     | 12 +++++-
>  3 files changed, 93 insertions(+), 1 deletion(-)
> 
> base-commit: 0879b944c95d65f7523d178d3addaebe84e510ec
> 
Hi Maxime,

Just tested these patches on Amlogic GXBB to provide 3D Mali acceleration on framebuffer.

Tested-by: Neil Armstrong <narmstrong@baylibre.com>

Thanks,
Neil

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web