From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/4] drm: add prime helpers Date: Thu, 6 Dec 2012 22:50:36 +0100 Message-ID: <20121206215036.GW11556@phenom.ffwll.local> References: <1354817271-5121-1-git-send-email-aplattner@nvidia.com> <1354817271-5121-2-git-send-email-aplattner@nvidia.com> <20121206214630.GV11556@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ea0-f177.google.com (mail-ea0-f177.google.com [209.85.215.177]) by gabe.freedesktop.org (Postfix) with ESMTP id 9E64DE5C00 for ; Thu, 6 Dec 2012 13:49:07 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id c10so2648940eaa.36 for ; Thu, 06 Dec 2012 13:49:06 -0800 (PST) Content-Disposition: inline In-Reply-To: <20121206214630.GV11556@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Aaron Plattner Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Thu, Dec 06, 2012 at 10:46:30PM +0100, Daniel Vetter wrote: > On Thu, Dec 06, 2012 at 10:07:48AM -0800, Aaron Plattner wrote: > > Instead of reimplementing all of the dma_buf functionality in every driver, > > create helpers drm_prime_import and drm_prime_export that implement them in > > terms of new, lower-level hook functions: > > > > gem_prime_pin: callback when a buffer is created, used to pin buffers into GTT > > gem_prime_get_pages: convert a drm_gem_object to an sg_table for export > > gem_prime_import_sg: convert an sg_table into a drm_gem_object > > gem_prime_vmap, gem_prime_vunmap: map and unmap an object > > > > These hooks are optional; drivers can opt in by using drm_gem_prime_import and > > drm_gem_prime_export as the .gem_prime_import and .gem_prime_export fields of > > struct drm_driver. > > > > Signed-off-by: Aaron Plattner > > A few comments: > > - Can you please add kerneldoc entries for these new helpers? Laurent > Pinchart started a nice drm kerneldoc as an overview. And since then > we've at least integrated the kerneldoc api reference at a nice place > there and brushed it up a bit when touching drm core or helpers in a > bigger patch series. See e.g. my recent dp helper series for what I'm > looking for. I think we should have kerneldoc at least for the exported > functions. > > - Just an idea for all the essential noop cpu helpers: Maybe just call > them dma_buf*noop and shovel them as convenience helpers into the > dma-buf.c code in the core, for drivers that don't want/can't/won't > bother to implement the cpu access support. Related: Exporting the > functions in general so that drivers could pick&choose One more: For the cpu access noop helpers I'd vote for -ENOTTY as the more canonical "not implemented error, you're talking to the wrong thing" error instead of -EINVAL, which an exporter could throw back to the importer if e.g. the range is outside of the size of the dma_buf. With a quick dma_buf doc update we could then bless this as the official way to denounce cpu access support. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch