From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2181AC433EF for ; Fri, 1 Oct 2021 17:32:53 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DF10461A40 for ; Fri, 1 Oct 2021 17:32:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DF10461A40 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4IVZx9G67TKO1xcX6vS7tHjFtNP10f4FBnY4KSndbGQ=; b=HTWegEzwjNjaW7 t3hcWo1QFDRCvZvOobY3GIZ39UzHkGC6dUEYYVksVOfw1opLATCvJlavQTY72dG2SE5bmn3e5H/ZN bYwWFhPE12dl9CLDXi0nymrMJoO40yoKcjvxcJg1N+A1FTa+EJslTKDqwJrDApzlYwNBNDziAEuFf 5fVrVScxt0doedA8vaNwgoGn+VaCi0Vp+vXgjijgY97OmvL0/e90OOIqZCrcwmFIKrI3Eq4QshtpT Yd/KWibmXSr8pTCHiTeMiM2WqrIoLolk+r2MVyQSWhh0KCcsb/grNf0zlU7x90FaEbQJVXfqGV7on 1PmULnKb6/YbMuIzY2YQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWMN7-0011ni-BZ; Fri, 01 Oct 2021 17:30:57 +0000 Received: from bhuna.collabora.co.uk ([46.235.227.227]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWMN3-0011mY-4V for linux-arm-kernel@lists.infradead.org; Fri, 01 Oct 2021 17:30:55 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: alyssa) with ESMTPSA id D13E61F4579C Date: Fri, 1 Oct 2021 13:30:43 -0400 From: Alyssa Rosenzweig To: Boris Brezillon Cc: Steven Price , Joerg Roedel , iommu@lists.linux-foundation.org, Rob Herring , Tomeu Vizoso , Alyssa Rosenzweig , Robin Murphy , Will Deacon , linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2 4/5] drm/panfrost: Add a PANFROST_BO_GPUONLY flag Message-ID: References: <20211001143427.1564786-1-boris.brezillon@collabora.com> <20211001143427.1564786-5-boris.brezillon@collabora.com> <02cb188d-e77d-3dd6-ad62-fe56d42724ae@arm.com> <20211001182206.78eb87ab@collabora.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211001182206.78eb87ab@collabora.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211001_103053_358301_CD8B649C X-CRM114-Status: GOOD ( 22.70 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org > > This seems reasonable to me - it matches the kbase > > BASE_MEM_COHERENT_SYSTEM (only backwards obviously) and it worked > > reasonably well for the blob. Oh, is that what that was for? I remember seeing it set on Midgard for varyings. Good to go full circle now. > > But I'm wondering if we need to do anything special to deal with the > > fact we will now have some non-coherent mappings on an otherwise > > coherent device. > > > > There are certainly some oddities around how these buffers will be > > mapped into user space if requested, e.g. panfrost_gem_create_object() > > sets 'map_wc' based on pfdev->coherent which is arguably wrong for > > GPUONLY. So there are two things we could consider: > > > > a) Actually prevent user space mapping GPUONLY flagged buffers. Which > > matches the intention of the name. > > I intended to do that, just forgot to add wrappers around > drm_gem_shmem_{mmap,vmap}() to forbid CPU-mappings on gpuonly buffers. This feels like the cleaner solution to me. > > b) Attempt to provide user space with the tools to safely interact with > > the buffers (this is the kbase approach). This does have the benefit of > > allowing *mostly* GPU access. An example here is the tiler heap where > > the CPU could zero out as necessary but mostly the GPU has ownership and > > the CPU never reads the contents. GPUONLY/DEVONLY might not be the best > > name in that case. > > Uh, right, I forgot we had to zero the tiler heap on Midgard (most of > the time done with a WRITE_VALUE job, but there's an exception on some > old Midgard GPUs IIRC). "Attempt" is the key word here :| We indeed only touch the tiler heap from the CPU on v4, and life's too short to care about new optimizations for v4. Unless the patch is trivial, my vote is for a) preventing the mappings and only setting GPUONLY on the tiler_heap starting with v5. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel