From patchwork Tue Sep 29 15:41:56 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alex Deucher X-Patchwork-Id: 7287871 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 9C0229F1D5 for ; Tue, 29 Sep 2015 15:42:02 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7B23920641 for ; Tue, 29 Sep 2015 15:42:01 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 2310720648 for ; Tue, 29 Sep 2015 15:42:00 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 54F2F72120; Tue, 29 Sep 2015 08:41:59 -0700 (PDT) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by gabe.freedesktop.org (Postfix) with ESMTPS id CEC4272120 for ; Tue, 29 Sep 2015 08:41:57 -0700 (PDT) Received: by ykdg206 with SMTP id g206so10788247ykd.1 for ; Tue, 29 Sep 2015 08:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bYQIcZJCtIJNuE5Q44Pel6GjS56/WAanCdntxpTHTfc=; b=c5I9RlelHz9Q8PruYSe3IoCZJWrLQJRboOUksZ2lxULVsZmIgir+a5t5WCWmkz0KdW kO7wyRfs8iwbe/hJSRAJaeZWfEtQFNFqI12jH1EBfHc38eG5awxYEYpqoZqJ/X4k8DBm 0N5HX+eeXTvg5R5ggZxMIntyala/3TSJaAxsmlPptK31yRAQpRxduRtDR3aooF8eUyfz WtOz4+WD2bSbPksmd0hUazqlVVlQQkU/oP6EV44LICScGp/k4vdpKh6zI3Wd82OCRBvR 3sYrEsLwPmZAbtg9V9PSfVAeJqdTSFoN0UP7nwKIEWyldKOSH+Ivo+bwaGiOkaEHcEEA 9lNw== MIME-Version: 1.0 X-Received: by 10.170.163.4 with SMTP id f4mr22059575ykd.93.1443541317036; Tue, 29 Sep 2015 08:41:57 -0700 (PDT) Received: by 10.37.32.4 with HTTP; Tue, 29 Sep 2015 08:41:56 -0700 (PDT) In-Reply-To: <20150929152009.GO3383@phenom.ffwll.local> References: <1436458871-16358-1-git-send-email-alexander.deucher@amd.com> <1436458871-16358-7-git-send-email-alexander.deucher@amd.com> <20150929114048.GK3383@phenom.ffwll.local> <560A8695.3070506@vodafone.de> <20150929152009.GO3383@phenom.ffwll.local> Date: Tue, 29 Sep 2015 11:41:56 -0400 Message-ID: Subject: Re: [PATCH 07/12] drm/amdgpu: implement cgs gpu memory callbacks From: Alex Deucher To: Daniel Vetter Cc: Alex Deucher , "Bayyavarapu, Maruthi" , Maling list - DRI developers X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Sep 29, 2015 at 11:20 AM, Daniel Vetter wrote: > On Tue, Sep 29, 2015 at 02:39:49PM +0200, Christian König wrote: >> On 29.09.2015 13:40, Daniel Vetter wrote: >> >On Thu, Jul 09, 2015 at 12:21:06PM -0400, Alex Deucher wrote: >> >>From: Chunming Zhou >> >> >> >>This implements the cgs interface for allocating >> >>GPU memory. >> >> >> >>Reviewed-by: Jammy Zhou >> >I don't see that review anywhere on a m-l ... where is it? >> >> Jammy reviewed the stuff internally before we made it public, that's why you >> can't find it. >> >> > >> >I stumbled over this patch because it adds a new dev->struct_mutex user >> >(that should be a big warning sign) and then I somehow unrolled some giant >> >chain of wtfs. Either I'm completely missing what this is used for or it >> >probably should get reworked asap. >> >> The CGS functions aren't used at the moment because none of the components >> depending on them made it into the kernel, but we wanted to keep it so that >> we can get reviews on the general idea and if necessary rework it. >> >> In general it's an abstraction layer of device driver dependent functions >> which enables us to share more code internally. >> >> We worked quite hard on trying to avoid the OS abstraction trap with this, >> but if you think this still won't work feel free to object. > > The bit that made me look really is the import_gpu_mem thing, which seems > to partially reinvent drm_prime.c. Given how tricky importing and > import-caching is I'd really like to see that gone (and Alex said on irc > he'd be ok with that). > See attached patch. It was really only added for completeness. We don't have any users of it at the moment. If we end up needing the functionality in the future we can revisit it. > The other stuff seems a lot more benign. For the irq abstraction > specifically it might be worth looking at the irq_chip stuff linux core > has, which is what's used to virtualize/abstract irq routing and handling. > But for that stuff it's a balance thing really how much you reinvent > wheels internally in the driver (e.g. i915 has it's own power_well stuff > which is pretty much just powerdomains reinvented, with less features). > I think that's one of the hardest things in the kernel: finding out if a solution already exists or not. We implemented our own version of mfd for our ACP audio block driver. Upon upsteaming we were alerted to mfd's existence and we converted the driver to use mfd. At the end of the day it was a lot of work for minimal gain, at least from a functionality perspective. I wish we had known about it sooner. I'll take a look at the irq_chip stuff. Thanks for the heads up! Alex > But really I can't tell without the users whether I'd expect this to be > hurt longterm or not for you ;-) But the import stuff is hurt for me since > you noodle around in drm internals. And specifically I'd like to make > modern drivers completely struct_mutex free with the goal to untangle the > last hold-outs of that lock in the drm core. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch Reviewed-by: Daniel Vetter From 013170490a934731bb5fbc4cb8ee46421d2f240e Mon Sep 17 00:00:00 2001 From: Alex Deucher Date: Tue, 29 Sep 2015 10:35:45 -0400 Subject: [PATCH] drm/amdgpu/cgs: remove import_gpu_mem It was added for completeness, but we don't have any users for it yet. Daniel Vetter noted that it may be racy. Remove it. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c | 39 --------------------------------- drivers/gpu/drm/amd/include/cgs_linux.h | 17 -------------- 2 files changed, 56 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c index 25be402..7949927 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c @@ -208,44 +208,6 @@ static int amdgpu_cgs_alloc_gpu_mem(void *cgs_device, return ret; } -static int amdgpu_cgs_import_gpu_mem(void *cgs_device, int dmabuf_fd, - cgs_handle_t *handle) -{ - CGS_FUNC_ADEV; - int r; - uint32_t dma_handle; - struct drm_gem_object *obj; - struct amdgpu_bo *bo; - struct drm_device *dev = adev->ddev; - struct drm_file *file_priv = NULL, *priv; - - mutex_lock(&dev->struct_mutex); - list_for_each_entry(priv, &dev->filelist, lhead) { - rcu_read_lock(); - if (priv->pid == get_pid(task_pid(current))) - file_priv = priv; - rcu_read_unlock(); - if (file_priv) - break; - } - mutex_unlock(&dev->struct_mutex); - r = dev->driver->prime_fd_to_handle(dev, - file_priv, dmabuf_fd, - &dma_handle); - spin_lock(&file_priv->table_lock); - - /* Check if we currently have a reference on the object */ - obj = idr_find(&file_priv->object_idr, dma_handle); - if (obj == NULL) { - spin_unlock(&file_priv->table_lock); - return -EINVAL; - } - spin_unlock(&file_priv->table_lock); - bo = gem_to_amdgpu_bo(obj); - *handle = (cgs_handle_t)bo; - return 0; -} - static int amdgpu_cgs_free_gpu_mem(void *cgs_device, cgs_handle_t handle) { struct amdgpu_bo *obj = (struct amdgpu_bo *)handle; @@ -846,7 +808,6 @@ static const struct cgs_ops amdgpu_cgs_ops = { }; static const struct cgs_os_ops amdgpu_cgs_os_ops = { - amdgpu_cgs_import_gpu_mem, amdgpu_cgs_add_irq_source, amdgpu_cgs_irq_get, amdgpu_cgs_irq_put diff --git a/drivers/gpu/drm/amd/include/cgs_linux.h b/drivers/gpu/drm/amd/include/cgs_linux.h index 488642f..3b47ae3 100644 --- a/drivers/gpu/drm/amd/include/cgs_linux.h +++ b/drivers/gpu/drm/amd/include/cgs_linux.h @@ -27,19 +27,6 @@ #include "cgs_common.h" /** - * cgs_import_gpu_mem() - Import dmabuf handle - * @cgs_device: opaque device handle - * @dmabuf_fd: DMABuf file descriptor - * @handle: memory handle (output) - * - * Must be called in the process context that dmabuf_fd belongs to. - * - * Return: 0 on success, -errno otherwise - */ -typedef int (*cgs_import_gpu_mem_t)(void *cgs_device, int dmabuf_fd, - cgs_handle_t *handle); - -/** * cgs_irq_source_set_func() - Callback for enabling/disabling interrupt sources * @private_data: private data provided to cgs_add_irq_source * @src_id: interrupt source ID @@ -114,16 +101,12 @@ typedef int (*cgs_irq_get_t)(void *cgs_device, unsigned src_id, unsigned type); typedef int (*cgs_irq_put_t)(void *cgs_device, unsigned src_id, unsigned type); struct cgs_os_ops { - cgs_import_gpu_mem_t import_gpu_mem; - /* IRQ handling */ cgs_add_irq_source_t add_irq_source; cgs_irq_get_t irq_get; cgs_irq_put_t irq_put; }; -#define cgs_import_gpu_mem(dev,dmabuf_fd,handle) \ - CGS_OS_CALL(import_gpu_mem,dev,dmabuf_fd,handle) #define cgs_add_irq_source(dev,src_id,num_types,set,handler,private_data) \ CGS_OS_CALL(add_irq_source,dev,src_id,num_types,set,handler, \ private_data) -- 1.8.3.1