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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75BB0C31E40 for ; Tue, 6 Aug 2019 15:51:02 +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 4789C20717 for ; Tue, 6 Aug 2019 15:51:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Tf1nQkzq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4789C20717 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject: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=5JyTVch6+JYBleEVfBMPDtb7cA5fizwAaGX7HL0D024=; b=Tf1nQkzq/m41jy z8VqsRCtCW3XpHihhGrTkx4r97kZefNqur62yCq3tupdrh4q5GIxWWZGlQ2Sq56izUYFLhwduCUaY oNENtDpfqBYrPYDTBLdBSDWdMDye3QPQ0sSMQTDB8wxzjz5SgOm5qokg9sxhKj+qSfwQ17KJ4jyd2 xnYhyRlJvPEAkTBPH0KAf3+viKp6t3Xvv2Etz48jEWqkNWSd8G6H5oMZKJgUjFeZ5nYBNIu+7Ay8x 9Syd+y1xm9tNCh+IV24BgEFsTYDV98X/nhP/dYE8eeetcwmOc9d9XwPOVrpQ73puIHfr+a9YW+JUp YP8ey7/zYO//ZbL3bMxw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hv1jh-0001ss-IK; Tue, 06 Aug 2019 15:50:53 +0000 Received: from verein.lst.de ([213.95.11.211]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hv1je-0001oa-2W for linux-arm-kernel@lists.infradead.org; Tue, 06 Aug 2019 15:50:51 +0000 Received: by verein.lst.de (Postfix, from userid 2407) id 125CC227A81; Tue, 6 Aug 2019 17:50:45 +0200 (CEST) Date: Tue, 6 Aug 2019 17:50:44 +0200 From: Christoph Hellwig To: Rob Clark Subject: Re: [PATCH 1/2] drm: add cache support for arm64 Message-ID: <20190806155044.GC25050@lst.de> References: <20190805211451.20176-1-robdclark@gmail.com> <20190806084821.GA17129@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190806_085050_296536_5EA5CC88 X-CRM114-Status: GOOD ( 13.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sean Paul , Maxime Ripard , Catalin Marinas , Maarten Lankhorst , LKML , dri-devel , David Airlie , Rob Clark , linux-arm-kernel@lists.infradead.org, Daniel Vetter , Greg Kroah-Hartman , Thomas Gleixner , Will Deacon , Christoph Hellwig , Allison Randal Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Aug 06, 2019 at 07:11:41AM -0700, Rob Clark wrote: > Agreed that drm_cflush_* isn't a great API. In this particular case > (IIUC), I need wb+inv so that there aren't dirty cache lines that drop > out to memory later, and so that I don't get a cache hit on > uncached/wc mmap'ing. So what is the use case here? Allocate pages using the page allocator (or CMA for that matter), and then mmaping them to userspace and never touching them again from the kernel? > Tying it in w/ iommu seems a bit weird to me.. but maybe that is just > me, I'm certainly willing to consider proposals or to try things and > see how they work out. This was just my through as the fit seems easy. But maybe you'll need to explain your use case(s) a bit more so that we can figure out what a good high level API is. > Exposing the arch_sync_* API and using that directly (bypassing > drm_cflush_*) actually seems pretty reasonable and pragmatic. I did > have one doubt, as phys_to_virt() is only valid for kernel direct > mapped memory (AFAIU), what happens for pages that are not in kernel > linear map? Maybe it is ok to ignore those pages, since they won't > have an aliased mapping? They could have an aliased mapping in vmalloc/vmap space for example, if you created one. We have the flush_kernel_vmap_range / invalidate_kernel_vmap_range APIs for those, that are implement on architectures with VIVT caches. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 1/2] drm: add cache support for arm64 Date: Tue, 6 Aug 2019 17:50:44 +0200 Message-ID: <20190806155044.GC25050@lst.de> References: <20190805211451.20176-1-robdclark@gmail.com> <20190806084821.GA17129@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Rob Clark Cc: Christoph Hellwig , Rob Clark , dri-devel , Catalin Marinas , Will Deacon , Maarten Lankhorst , Maxime Ripard , Sean Paul , David Airlie , Daniel Vetter , Allison Randal , Greg Kroah-Hartman , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, LKML List-Id: dri-devel@lists.freedesktop.org On Tue, Aug 06, 2019 at 07:11:41AM -0700, Rob Clark wrote: > Agreed that drm_cflush_* isn't a great API. In this particular case > (IIUC), I need wb+inv so that there aren't dirty cache lines that drop > out to memory later, and so that I don't get a cache hit on > uncached/wc mmap'ing. So what is the use case here? Allocate pages using the page allocator (or CMA for that matter), and then mmaping them to userspace and never touching them again from the kernel? > Tying it in w/ iommu seems a bit weird to me.. but maybe that is just > me, I'm certainly willing to consider proposals or to try things and > see how they work out. This was just my through as the fit seems easy. But maybe you'll need to explain your use case(s) a bit more so that we can figure out what a good high level API is. > Exposing the arch_sync_* API and using that directly (bypassing > drm_cflush_*) actually seems pretty reasonable and pragmatic. I did > have one doubt, as phys_to_virt() is only valid for kernel direct > mapped memory (AFAIU), what happens for pages that are not in kernel > linear map? Maybe it is ok to ignore those pages, since they won't > have an aliased mapping? They could have an aliased mapping in vmalloc/vmap space for example, if you created one. We have the flush_kernel_vmap_range / invalidate_kernel_vmap_range APIs for those, that are implement on architectures with VIVT caches.