Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3939265imu; Mon, 28 Jan 2019 13:45:31 -0800 (PST) X-Google-Smtp-Source: ALg8bN7UfABSkvreyJD17ObR2ntEyioH61z1jZwMeHdK7puT4roktsZgr6KgNG13cOwNNirt5hZp X-Received: by 2002:a63:2e88:: with SMTP id u130mr21764223pgu.9.1548711931023; Mon, 28 Jan 2019 13:45:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548711930; cv=none; d=google.com; s=arc-20160816; b=TItTeyZkcAzcDRbXx6vKFoUvwfM7dkqzkoTeHmxtLhOkcQXev9D+eFG1ejsLtsOJcS rj0Yy5ShEWDVujNXQwnaupCycosVcLkGwmsHUVCFPBlbPSrVu/g3TF3jTuJpEakF28U2 xsJSoagRYE7NgDHz7HaoYrkXetdm5UHvnTJBnVptrUaE35pDD1w0xTUgykXmIxBStMuI qanwp+D86ReQNGVxjKF/sPRMg7xp4YWym1tW8oSHMFrkftXAwqaG85I+rSqrDFiGJUi9 FBU/bZiS5M7LEW2FmqHwk9vsr8ia1VP4jw8hQ8U+1B24fKjbNBQ2t6NnN0bfLwIV/36B TlNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=eJYVz4EBlCraCUoDXhuuTUqA4MMStlZ+ifQ/w8CYW1U=; b=CE2YTHMhP0Vkzn+MlPRdSiXG42Yfa44clzHZTIzmm5T9de5TvbOu1doLSh7HqZbfsp LFyQa/a+uBJywnkvn6W7l801M+PZcwXH6GpT18Hmm6OPTeuMMFA5SAxxnt+ZfXG252rp flGuHakWJHgfBx+rh7c3frRDBxMHQ/Cl715Qz8iPhM8XbnbSAcO1j2SBo+SnAQ+ZPqcD 2p6NuYyuWqJ+GZPqH8KrEe4Wh7oQuKMpdfZlvxiGWfCxyfoTV6w1/OspyCl4uISVq/Cq VHPkaSPtgTgjL/V4+6OdQZ1k1iAgvd48yuv4v5ayVPO0IpV6Wg79q+144hhTJD1+1dlG fW/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b="AXNBr/e7"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f21si11631828pgb.371.2019.01.28.13.45.14; Mon, 28 Jan 2019 13:45:30 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b="AXNBr/e7"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727041AbfA1Vod (ORCPT + 99 others); Mon, 28 Jan 2019 16:44:33 -0500 Received: from lelv0143.ext.ti.com ([198.47.23.248]:39774 "EHLO lelv0143.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726802AbfA1Voc (ORCPT ); Mon, 28 Jan 2019 16:44:32 -0500 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id x0SLiB2r067581; Mon, 28 Jan 2019 15:44:11 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1548711851; bh=eJYVz4EBlCraCUoDXhuuTUqA4MMStlZ+ifQ/w8CYW1U=; h=From:To:CC:Subject:Date; b=AXNBr/e75p2LyAqnEO+U8jcZzbvKyqr0bXHW1OIDlelahiB8ifQCokPbnQVWBRjxL 9UNhJ9t1h8q9s67iq04aUrQIo/uaLFd61MZ3NAvofOQEa7mZrD2ny1xb5EEK9pjx0O OjIpgcaYzczFGnSckZMrXCBeJJPl92uDCGvyAm84= Received: from DFLE112.ent.ti.com (dfle112.ent.ti.com [10.64.6.33]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTPS id x0SLiB1K031955 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 28 Jan 2019 15:44:11 -0600 Received: from DFLE108.ent.ti.com (10.64.6.29) by DFLE112.ent.ti.com (10.64.6.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 28 Jan 2019 15:44:11 -0600 Received: from dlep32.itg.ti.com (157.170.170.100) by DFLE108.ent.ti.com (10.64.6.29) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1591.10 via Frontend Transport; Mon, 28 Jan 2019 15:44:11 -0600 Received: from legion.dal.desgin.ti.com (legion.dal.design.ti.com [128.247.22.53]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id x0SLiBew025858; Mon, 28 Jan 2019 15:44:11 -0600 Received: from localhost (uda0226330.dhcp.ti.com [172.22.93.231]) by legion.dal.desgin.ti.com (8.11.7p1+Sun/8.11.7) with ESMTP id x0SLi9U02629; Mon, 28 Jan 2019 15:44:09 -0600 (CST) From: "Andrew F. Davis" To: Laura Abbott , Sumit Semwal , Greg Kroah-Hartman , =?UTF-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= , Christoph Hellwig , Liam Mark , Brian Starkey CC: , , , "Andrew F . Davis" Subject: [PATCH v2] staging: android: ion: Allocate from heap ID directly without mask Date: Mon, 28 Jan 2019 15:44:08 -0600 Message-ID: <20190128214408.25442-1-afd@ti.com> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Previously the heap to allocate from was selected by a mask of allowed heap types. This may have been done as a primitive form of constraint solving, the first heap type that matched any set bit of the heap mask was allocated from, unless that heap was excluded by having its heap ID bit not set in the separate passed in heap ID mask. The heap type does not really represent constraints that should be matched against to begin with. So the patch [0] removed the the heap type mask matching but unfortunately left the heap ID mask check (possibly by mistake or to preserve API). Therefor we now only have a mask of heap IDs, but heap IDs are unique identifiers and have nothing to do with the underlying heap, so mask matching is not useful here. This also limits us to 32 heaps total in a system. With the heap query API users can find the right heap based on type or name themselves then just supply the ID for that heap. Remove heap ID mask and allow users to specify heap ID directly by its number. I know this is an ABI break, but we are in staging so lets get this over with now rather than limit ourselves later. [0] commit 2bb9f5034ec7 ("gpu: ion: Remove heapmask from client") Signed-off-by: Andrew F. Davis --- This also means we don't need to store the available heaps in a plist, we only operation we care about is lookup, so a better data structure should be chosen at some point, regular list or xarray maybe? This is base on -next as to be on top of the other taken Ion patches. Changes from v1: - Fix spelling in commit message - Cleanup logic per Brian's suggestion drivers/staging/android/ion/ion.c | 28 +++++++++++++--------------- drivers/staging/android/uapi/ion.h | 6 ++---- 2 files changed, 15 insertions(+), 19 deletions(-) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 92c2914239e3..b0b0d0b587c2 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -387,7 +387,7 @@ static const struct dma_buf_ops dma_buf_ops = { .unmap = ion_dma_buf_kunmap, }; -static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags) +static int ion_alloc(size_t len, unsigned int heap_id, unsigned int flags) { struct ion_device *dev = internal_dev; struct ion_buffer *buffer = NULL; @@ -396,27 +396,25 @@ static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags) int fd; struct dma_buf *dmabuf; - pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__, - len, heap_id_mask, flags); - /* - * traverse the list of heaps available in this system in priority - * order. If the heap type is supported by the client, and matches the - * request of the caller allocate from it. Repeat until allocate has - * succeeded or all heaps have been tried - */ + pr_debug("%s: len %zu heap_id %u flags %x\n", __func__, + len, heap_id, flags); + len = PAGE_ALIGN(len); if (!len) return -EINVAL; + /* + * Traverse the list of heaps available in this system. If the + * heap id matches the request of the caller allocate from it. + */ down_read(&dev->lock); plist_for_each_entry(heap, &dev->heaps, node) { - /* if the caller didn't specify this heap id */ - if (!((1 << heap->id) & heap_id_mask)) - continue; - buffer = ion_buffer_create(heap, dev, len, flags); - if (!IS_ERR(buffer)) + /* if the caller specified this heap id */ + if (heap->id == heap_id) { + buffer = ion_buffer_create(heap, dev, len, flags); break; + } } up_read(&dev->lock); @@ -541,7 +539,7 @@ static long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) int fd; fd = ion_alloc(data.allocation.len, - data.allocation.heap_id_mask, + data.allocation.heap_id, data.allocation.flags); if (fd < 0) return fd; diff --git a/drivers/staging/android/uapi/ion.h b/drivers/staging/android/uapi/ion.h index 5d7009884c13..6a78a1e23251 100644 --- a/drivers/staging/android/uapi/ion.h +++ b/drivers/staging/android/uapi/ion.h @@ -35,8 +35,6 @@ enum ion_heap_type { */ }; -#define ION_NUM_HEAP_IDS (sizeof(unsigned int) * 8) - /** * allocation flags - the lower 16 bits are used by core ion, the upper 16 * bits are reserved for use by the heaps themselves. @@ -59,7 +57,7 @@ enum ion_heap_type { /** * struct ion_allocation_data - metadata passed from userspace for allocations * @len: size of the allocation - * @heap_id_mask: mask of heap ids to allocate from + * @heap_id: heap id to allocate from * @flags: flags passed to heap * @handle: pointer that will be populated with a cookie to use to * refer to this allocation @@ -68,7 +66,7 @@ enum ion_heap_type { */ struct ion_allocation_data { __u64 len; - __u32 heap_id_mask; + __u32 heap_id; __u32 flags; __u32 fd; __u32 unused; -- 2.19.1