drm/fb_cma_helper: Implement fb_mmap callback

From: Robin Murphy <robin.murphy@arm.com>

BugLink: https://bugs.launchpad.net/bugs/1708417

In the absence of an fb_mmap callback, the fbdev code falls back to a
naive implementation which relies upon the DMA address being the same
as the physical address, and the buffer being physically contiguous
from there. Whilst this often holds for standard CMA allocations via
the platform's regular DMA ops, if the allocation is provided by an
IOMMU then such assumptions can fall apart spectacularly.

To resolve this, reroute the fb_mmap call to the appropriate DMA API
implementation, as per the other cma_helper calls.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/8fd95ac1440e0f01daad6d4380be3a4c8fa61055.1465301219.git.robin.murphy@arm.com
(cherry picked from commit ce0c5757681052eb8965209129f28362c3a4d8a7)
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 8 ++++++++
 1 file changed, 8 insertions(+)

On 03.08.2017 12:17, Paolo Pisati wrote:
> From: Robin Murphy <robin.murphy@arm.com>
> 
> BugLink: https://bugs.launchpad.net/bugs/1708417
> 
> In the absence of an fb_mmap callback, the fbdev code falls back to a
> naive implementation which relies upon the DMA address being the same
> as the physical address, and the buffer being physically contiguous
> from there. Whilst this often holds for standard CMA allocations via
> the platform's regular DMA ops, if the allocation is provided by an
> IOMMU then such assumptions can fall apart spectacularly.
> 
> To resolve this, reroute the fb_mmap call to the appropriate DMA API
> implementation, as per the other cma_helper calls.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Link: http://patchwork.freedesktop.org/patch/msgid/8fd95ac1440e0f01daad6d4380be3a4c8fa61055.1465301219.git.robin.murphy@arm.com
> (cherry picked from commit ce0c5757681052eb8965209129f28362c3a4d8a7)
> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>

> ---

Limited to specific subtree where it is testable.

>  drivers/gpu/drm/drm_fb_cma_helper.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 6349d0c..033f846 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -23,6 +23,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
>  #include <drm/drm_fb_cma_helper.h>
> +#include <linux/dma-mapping.h>
>  #include <linux/module.h>
>  
>  struct drm_fb_cma {
> @@ -220,6 +221,12 @@ int drm_fb_cma_debugfs_show(struct seq_file *m, void *arg)
>  EXPORT_SYMBOL_GPL(drm_fb_cma_debugfs_show);
>  #endif
>  
> +static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
> +{
> +	return dma_mmap_writecombine(info->device, vma, info->screen_base,
> +				     info->fix.smem_start, info->fix.smem_len);
> +}
> +
>  static struct fb_ops drm_fbdev_cma_ops = {
>  	.owner		= THIS_MODULE,
>  	.fb_fillrect	= drm_fb_helper_sys_fillrect,
> @@ -230,6 +237,7 @@ static struct fb_ops drm_fbdev_cma_ops = {
>  	.fb_blank	= drm_fb_helper_blank,
>  	.fb_pan_display	= drm_fb_helper_pan_display,
>  	.fb_setcmap	= drm_fb_helper_setcmap,
> +	.fb_mmap	= drm_fb_cma_mmap,
>  };
>  
>  static int drm_fbdev_cma_create(struct drm_fb_helper *helper,
>

On 08/03/17 12:17, Paolo Pisati wrote:
> From: Robin Murphy <robin.murphy@arm.com>
> 
> BugLink: https://bugs.launchpad.net/bugs/1708417
> 
> In the absence of an fb_mmap callback, the fbdev code falls back to a
> naive implementation which relies upon the DMA address being the same
> as the physical address, and the buffer being physically contiguous
> from there. Whilst this often holds for standard CMA allocations via
> the platform's regular DMA ops, if the allocation is provided by an
> IOMMU then such assumptions can fall apart spectacularly.
> 
> To resolve this, reroute the fb_mmap call to the appropriate DMA API
> implementation, as per the other cma_helper calls.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Link: http://patchwork.freedesktop.org/patch/msgid/8fd95ac1440e0f01daad6d4380be3a4c8fa61055.1465301219.git.robin.murphy@arm.com
> (cherry picked from commit ce0c5757681052eb8965209129f28362c3a4d8a7)
> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>

Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

> ---
>  drivers/gpu/drm/drm_fb_cma_helper.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 6349d0c..033f846 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -23,6 +23,7 @@
>  #include <drm/drm_crtc_helper.h>
>  #include <drm/drm_gem_cma_helper.h>
>  #include <drm/drm_fb_cma_helper.h>
> +#include <linux/dma-mapping.h>
>  #include <linux/module.h>
>  
>  struct drm_fb_cma {
> @@ -220,6 +221,12 @@ int drm_fb_cma_debugfs_show(struct seq_file *m, void *arg)
>  EXPORT_SYMBOL_GPL(drm_fb_cma_debugfs_show);
>  #endif
>  
> +static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
> +{
> +	return dma_mmap_writecombine(info->device, vma, info->screen_base,
> +				     info->fix.smem_start, info->fix.smem_len);
> +}
> +
>  static struct fb_ops drm_fbdev_cma_ops = {
>  	.owner		= THIS_MODULE,
>  	.fb_fillrect	= drm_fb_helper_sys_fillrect,
> @@ -230,6 +237,7 @@ static struct fb_ops drm_fbdev_cma_ops = {
>  	.fb_blank	= drm_fb_helper_blank,
>  	.fb_pan_display	= drm_fb_helper_pan_display,
>  	.fb_setcmap	= drm_fb_helper_setcmap,
> +	.fb_mmap	= drm_fb_cma_mmap,
>  };
>  
>  static int drm_fbdev_cma_create(struct drm_fb_helper *helper,
>

Applied on xenial/raspi2 branch. Thanks.