From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755575AbcFGOnM (ORCPT ); Tue, 7 Jun 2016 10:43:12 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35701 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753260AbcFGOnJ (ORCPT ); Tue, 7 Jun 2016 10:43:09 -0400 Date: Tue, 7 Jun 2016 16:43:05 +0200 From: Daniel Vetter To: Robin Murphy Cc: airlied@linux.ie, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, daniel.vetter@ffwll.ch, liviu.dudau@arm.com Subject: Re: [PATCH] drm/fb_cma_helper: Implement fb_mmap callback Message-ID: <20160607144305.GC3363@phenom.ffwll.local> Mail-Followup-To: Robin Murphy , airlied@linux.ie, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, liviu.dudau@arm.com References: <8fd95ac1440e0f01daad6d4380be3a4c8fa61055.1465301219.git.robin.murphy@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8fd95ac1440e0f01daad6d4380be3a4c8fa61055.1465301219.git.robin.murphy@arm.com> X-Operating-System: Linux phenom 4.6.0-rc5+ User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 07, 2016 at 01:18:09PM +0100, Robin Murphy wrote: > 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. > > Acked-by: Daniel Vetter > Signed-off-by: Robin Murphy > --- > > Resending rebased to 4.7-rc1 with Daniel's ack. I know Russell raised > some concerns about the general way fb_cma_helper uses fb_info[1], but > AFAICS that's a longstanding separate problem orthogonal to this patch. Do you want me to pull this in through drm-misc, or will this land through some driver tree? Note that I'll do -misc pulls about every week, so if you don't send your pull this week I'd like to pull it in to avoid hilarity^W needless conflicts. -Daniel > > Robin. > > [1]:http://thread.gmane.org/gmane.comp.video.dri.devel/149288 > > 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 172cafe11c71..a25afc068d3f 100644 > --- a/drivers/gpu/drm/drm_fb_cma_helper.c > +++ b/drivers/gpu/drm/drm_fb_cma_helper.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > #include > > #define DEFAULT_FBDEFIO_DELAY_MS 50 > @@ -297,6 +298,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, > @@ -307,6 +314,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_deferred_io_mmap(struct fb_info *info, > -- > 2.8.1.dirty > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch