Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1209971pxb; Fri, 1 Apr 2022 07:27:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyatkL4b/WnjbIyBgShAekwaZZtT8pJuHHotsFyMw/rZn5G9A4OyD+k+ReXAnJdxYwHH/0V X-Received: by 2002:a17:902:7482:b0:156:3489:88b3 with SMTP id h2-20020a170902748200b00156348988b3mr10763513pll.86.1648823275449; Fri, 01 Apr 2022 07:27:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1648823275; cv=none; d=google.com; s=arc-20160816; b=Beu62v3UzrH2IbA9JiQEsWCAA31l8FhlJi0RmXBRtckQpVq7NzmVe6nPyph3SbnGfy iHfUI394FB008gsuL+sMeqtTgQ1fCdN3R0kJsxJ5xrgcCZS+1CYUfzFPEKDQARboa0xo Pgotuje6c8be2yCc6Bi2EG1QbVCnQHFVOtSJ/Ei3wPdjTKbU+OCBGrohn6Z+ptkvejz3 v0DMmp0yfU4GNNtcGNLbNpHOjRdgO8xjKco4N7RJWutRR3IgTp8J1XkZ8ngJHoDDa4ef d7tiK1t/arZh4gVorB01Me81F1ZX6/rKaZHZTRBTGnhRuAeGiQbvVvAXn+nj8bwElVjI XsNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:references :cc:to:from:content-language:subject:user-agent:mime-version:date :message-id:dkim-signature; bh=zcm5h/G5B5Z59Q01F0+kgFy5AAOcnDnGIRvXYuokmlI=; b=zvSyO5xBYFbw/iVQPxXaEPTnuZUaNEkHg9Xix2UoODgV88e2woK0Rir6K+GNWyFH8r nxTXU1E4uILtJ1gxNryNKQ2+KPhD5GxqkIi9kcjcacTdV2tKaU9EH4XuT4cudNKocGGd e/4k0l1btRDvH/GIqcESulVLKDQMgzmBgwAntRuk4KszJGWipXSke5NwZ6vPFHbyP+Y4 2yMbM45M2E6B/i8OchSHDAX4alaDSK8x3/p/Fu2ha2FxClkMWcq/oP1+lDnVTT5XcpcF 54+usFyB7ye8UEEUFDxdBW88B+LwPFAAe33pFNXAvBlMLndYcRG9HbUu66HW4bsOaswK FYgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=QxIKFkb3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j10-20020a170902f24a00b00153b2d16656si1989305plc.606.2022.04.01.07.27.41; Fri, 01 Apr 2022 07:27:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=QxIKFkb3; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237332AbiCaSy6 (ORCPT + 99 others); Thu, 31 Mar 2022 14:54:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232565AbiCaSy4 (ORCPT ); Thu, 31 Mar 2022 14:54:56 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2405A18D29B; Thu, 31 Mar 2022 11:53:09 -0700 (PDT) Received: from [IPV6:2a00:5f00:102:0:10b3:10ff:fe5d:4ec1] (unknown [IPv6:2a00:5f00:102:0:10b3:10ff:fe5d:4ec1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id C8AB41F471DE; Thu, 31 Mar 2022 19:53:06 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1648752788; bh=iCIU6s94N0rdvtHyebk6zzrjx7sdwliT90RWSSA/PjY=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=QxIKFkb3DId474h3e9jG30gDcVZzCZOMhdNiTb2bcxYnBfHPbWQcgfSvfNMCzkzBK f2BjoF5cJEiKaX6jGmrBcILxevzVOe0AkLOznm3SBBQ10jnflEnYxIVylm7a41KBOK FmzPJWSeI9oQ+lq7TCNyTXwXpHAdBzKzHhbJz8oQVRNHRI9a9UO+X1QIgubbt4c2rL 47xFUVvxjWofBY9j6eoh8iJkc7M+1PRnP4fwEDT9d0DowSatnocSwn2y3NbZO07i6n kkOQmELV13W1rLuGhsqZlQjqxHXFaLeteQbjCcor+y0BLHmBAiK0ESPCqUnvpoLM/u ZyDm0/klPfErQ== Message-ID: Date: Thu, 31 Mar 2022 21:53:04 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v2 10/10] drm/msm: Add a way for userspace to allocate GPU iova Content-Language: en-US From: Dmitry Osipenko To: Rob Clark , dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, Dmitry Baryshkov , Rob Clark , Sean Paul , Abhinav Kumar , David Airlie , Daniel Vetter , Akhil P Oommen , Jonathan Marek , Jordan Crouse , Emma Anholt , Dan Carpenter , open list References: <20220330204804.660819-1-robdclark@gmail.com> <20220330204804.660819-11-robdclark@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/31/22 21:52, Dmitry Osipenko wrote: > ... >> +/* >> + * Get the requested iova but don't pin it. Fails if the requested iova is >> + * not available. Doesn't need a put because iovas are currently valid for >> + * the life of the object. >> + * >> + * Setting an iova of zero will clear the vma. >> + */ >> +int msm_gem_set_iova(struct drm_gem_object *obj, >> + struct msm_gem_address_space *aspace, uint64_t iova) >> +{ >> + int ret = 0; > > nit: No need to initialize the ret > >> + msm_gem_lock(obj); >> + if (!iova) { >> + ret = clear_iova(obj, aspace); >> + } else { >> + struct msm_gem_vma *vma; >> + vma = get_vma_locked(obj, aspace, iova, iova + obj->size); >> + if (IS_ERR(vma)) { >> + ret = PTR_ERR(vma); >> + } else if (GEM_WARN_ON(vma->iova != iova)) { >> + clear_iova(obj, aspace); >> + ret = -ENOSPC; > > The (vma->iova != iova) means that vma is already set, but to a > different address. Is -ENOSPC really appropriate here? -EBUSY or -EINVAL > looks more natural to me. > >> + } >> + } >> + msm_gem_unlock(obj); >> + >> + return ret; >> +} >> + >> /* >> * Unpin a iova by updating the reference counts. The memory isn't actually >> * purged until something else (shrinker, mm_notifier, destroy, etc) decides >> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h >> index 38d66e1248b1..efa2e5c19f1e 100644 >> --- a/drivers/gpu/drm/msm/msm_gem.h >> +++ b/drivers/gpu/drm/msm/msm_gem.h >> @@ -38,6 +38,12 @@ struct msm_gem_address_space { >> >> /* @faults: the number of GPU hangs associated with this address space */ >> int faults; >> + >> + /** @va_start: lowest possible address to allocate */ >> + uint64_t va_start; >> + >> + /** @va_size: the size of the address space (in bytes) */ >> + uint64_t va_size; >> }; >> >> struct msm_gem_address_space * >> @@ -144,6 +150,8 @@ struct msm_gem_vma *msm_gem_get_vma_locked(struct drm_gem_object *obj, >> struct msm_gem_address_space *aspace); >> int msm_gem_get_iova(struct drm_gem_object *obj, >> struct msm_gem_address_space *aspace, uint64_t *iova); >> +int msm_gem_set_iova(struct drm_gem_object *obj, >> + struct msm_gem_address_space *aspace, uint64_t iova); >> int msm_gem_get_and_pin_iova_range(struct drm_gem_object *obj, >> struct msm_gem_address_space *aspace, uint64_t *iova, >> u64 range_start, u64 range_end); > nit: There is an odd mix of uint64_t and u64 (and alike) in the MSM code > :) The uint64_t variant shouldn't be used by kernel code in general and > checkpatch should want about it. s/want/warn/