From patchwork Wed Jul 24 11:30:18 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Zimmermann X-Patchwork-Id: 11056659 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0F69E13AC for ; Wed, 24 Jul 2019 11:30:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F36FD2868C for ; Wed, 24 Jul 2019 11:30:32 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E758D28786; Wed, 24 Jul 2019 11:30:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 877B22868C for ; Wed, 24 Jul 2019 11:30:32 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3239F6E4BE; Wed, 24 Jul 2019 11:30:31 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id EAE686E4BE for ; Wed, 24 Jul 2019 11:30:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3CD9DAE89; Wed, 24 Jul 2019 11:30:25 +0000 (UTC) From: Thomas Zimmermann To: daniel@ffwll.ch, kraxel@redhat.com, sam@ravnborg.org, airlied@redhat.com, yc_chen@aspeedtech.com, Christian.Koenig@amd.com Subject: [PATCH 1/3] drm/vram: Provide vmap and vunmap operations for GEM VRAM objects Date: Wed, 24 Jul 2019 13:30:18 +0200 Message-Id: <20190724113020.3752-2-tzimmermann@suse.de> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190724113020.3752-1-tzimmermann@suse.de> References: <20190724113020.3752-1-tzimmermann@suse.de> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thomas Zimmermann , dri-devel@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP The pattern of temporarily pinning and kmap-ing the BO's memory is common enough to justify helper functions that do and undo these operations. The implementation of vmap and vunmap for GEM VRAM helpers is already in PRIME helpers. The patch moves the operations to separate functions and exports them for general use. The patch also adds a note about possible kmap counting. So far this isn't required by drivers, but more complex use cases might make it necessary. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_gem_vram_helper.c | 55 ++++++++++++++++++++++----- include/drm/drm_gem_vram_helper.h | 12 ++++++ 2 files changed, 57 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c index e0fbfb6570cf..54758e4debca 100644 --- a/drivers/gpu/drm/drm_gem_vram_helper.c +++ b/drivers/gpu/drm/drm_gem_vram_helper.c @@ -340,6 +340,48 @@ void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo) } EXPORT_SYMBOL(drm_gem_vram_kunmap); +/** + * drm_gem_vram_vmap() - Pins and maps a GEM VRAM object into kernel address + space + * @gem: The GEM VRAM object to map + * + * The vmap function pins a GEM VRAM object to it's current location, either + * system or video memory, and maps it's buffer into kernel address space. As + * pinned object cannot be reloacted, you should not permanently pin objects. + * + * Returns: + * The buffer's virtual address on success, or + * an ERR_PTR()-encoded error code otherwise. + */ +void *drm_gem_vram_vmap(struct drm_gem_vram_object *gbo) +{ + int ret; + void *base; + + ret = drm_gem_vram_pin(gbo, 0); + if (ret) + return ERR_PTR(ret); + base = drm_gem_vram_kmap(gbo, true, NULL); + if (IS_ERR(base)) { + drm_gem_vram_unpin(gbo); + return base; + } + return base; +} +EXPORT_SYMBOL(drm_gem_vram_vmap); + +/** + * drm_gem_vram_vunmap() - Unmaps and unpins a GEM VRAM object + * @gem: The GEM VRAM object to unmap + * @vaddr: The mapping's base address + */ +void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, void *vaddr) +{ + drm_gem_vram_kunmap(gbo); + drm_gem_vram_unpin(gbo); +} +EXPORT_SYMBOL(drm_gem_vram_vunmap); + /** * drm_gem_vram_fill_create_dumb() - \ Helper for implementing &struct drm_driver.dumb_create @@ -595,17 +637,11 @@ static void drm_gem_vram_object_unpin(struct drm_gem_object *gem) static void *drm_gem_vram_object_vmap(struct drm_gem_object *gem) { struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem); - int ret; void *base; - ret = drm_gem_vram_pin(gbo, 0); - if (ret) + base = drm_gem_vram_vmap(gbo); + if (IS_ERR(base)) return NULL; - base = drm_gem_vram_kmap(gbo, true, NULL); - if (IS_ERR(base)) { - drm_gem_vram_unpin(gbo); - return NULL; - } return base; } @@ -620,8 +656,7 @@ static void drm_gem_vram_object_vunmap(struct drm_gem_object *gem, { struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem); - drm_gem_vram_kunmap(gbo); - drm_gem_vram_unpin(gbo); + drm_gem_vram_vunmap(gbo, vaddr); } /* diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h index b41d932eb53a..5192c169cec2 100644 --- a/include/drm/drm_gem_vram_helper.h +++ b/include/drm/drm_gem_vram_helper.h @@ -44,6 +44,16 @@ struct drm_gem_vram_object { struct ttm_placement placement; struct ttm_place placements[2]; + /* TODO: Maybe implement a map counter. + * + * So far, drivers based on VRAM helpers don't have overlapping + * mapping operations. A driver temporarily maps an object and + * unmaps it ASAP. This works well for fbdev emulation or cursors. + * + * If we ever have a driver with buffer objects that are mapped + * by multiple code fragments concurrently, we may need a map + * counter to get the mapping right. + */ int pin_count; }; @@ -84,6 +94,8 @@ int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo); void *drm_gem_vram_kmap(struct drm_gem_vram_object *gbo, bool map, bool *is_iomem); void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo); +void *drm_gem_vram_vmap(struct drm_gem_vram_object *gbo); +void drm_gem_vram_vunmap(struct drm_gem_vram_object *gbo, void *vaddr); int drm_gem_vram_fill_create_dumb(struct drm_file *file, struct drm_device *dev,