Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1055930pxu; Thu, 8 Oct 2020 02:01:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwpo1qCTdvSymXD80vxNiqK1mMeZ/D9B+xSOVAhj1+xz7LhW4D1ZG7m4A+Of5MVQg//ggAo X-Received: by 2002:a05:6402:3184:: with SMTP id di4mr8059579edb.362.1602147668226; Thu, 08 Oct 2020 02:01:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602147668; cv=none; d=google.com; s=arc-20160816; b=gn2GQ+/O58i8xmajHjKE0NYIbyEGMufSw9M7HW30HxUl52YryzSwrk35HaxlzCzpKA smH6aCX+O9jb2T7XPCk0JExdU3JMnqo1ytiB5/DZzKvrU1cgLuwfypA9aFiPKRZAjexM eKZnoAoXW9JDcByB5o5MHua+dCqWbQ1DTrdzCGiYSA+BUqclxp3XWMejQZWizig2MBBx ZvHP2OrXGB5gTJqtSVUSIPTomzrUQtOZ3+eIZ0KQzBUC+vq3uT2FHHm/aO7Vb+cc8VGA 8O8MED5lfnpTI47E2JXW8loTPRbn2UM6tbwv6PvQNj/KGTjpEpC0dumpVKHycJSyQFCI 0KPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=vIYdtmnIA2fow+CwZUdC8qokVXf/ESHX1nTBbZmaB44=; b=WToaci68e6wlDPcJkE2m48YnWH615xloBIAW8wHPADtyJcw91Dn9PO6hk+jOFhZIbh 2wYj/im5Hpvfp5KwUc1SDMSRUTMuL8JOTRQgW65Sc/52cxA9V0UAodGvnM3XIc14wGAt nhCLseG+WgpvZDDVrzrHis8DV6rCP2Tds4lAr4QteiKqmPfBh/WIeJ/QXMTaHfwqhK3P 31GbiR5QWCJNFxDL4J+BBI8a8KpdZ0phkljEkg3OpkMPZOny4RpZ2JEdS9bBFFCvg0g4 sMqUnxTjfS76W4xva2F9Sn3KWc6qW/QcA9+1ocQVSndOMUMQ0+A+x6YLLpCo6aVsSogj QnaQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l17si3265750ejq.235.2020.10.08.02.00.44; Thu, 08 Oct 2020 02:01:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728037AbgJHI2C (ORCPT + 99 others); Thu, 8 Oct 2020 04:28:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725907AbgJHI2B (ORCPT ); Thu, 8 Oct 2020 04:28:01 -0400 Received: from theia.8bytes.org (8bytes.org [IPv6:2a01:238:4383:600:38bc:a715:4b6d:a889]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C00BC061755; Thu, 8 Oct 2020 01:28:01 -0700 (PDT) Received: by theia.8bytes.org (Postfix, from userid 1000) id 5FA562FB; Thu, 8 Oct 2020 10:27:59 +0200 (CEST) Date: Thu, 8 Oct 2020 10:27:57 +0200 From: Joerg Roedel To: Christoph Hellwig Cc: Jonathan Marek , freedreno@lists.freedesktop.org, Rob Clark , Sean Paul , David Airlie , Daniel Vetter , "open list:DRM DRIVER FOR MSM ADRENO GPU" , "open list:DRM DRIVER FOR MSM ADRENO GPU" , open list , iommu@lists.linux-foundation.org, Robin Murphy Subject: Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance Message-ID: <20201008082757.GB3107@8bytes.org> References: <20201001002709.21361-1-jonathan@marek.ca> <20201001002709.21361-3-jonathan@marek.ca> <20201002075321.GA7547@infradead.org> <20201005082914.GA31702@infradead.org> <3e0b91be-e4a4-4ea5-7d58-6e71b8d51932@marek.ca> <20201006072306.GA12834@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201006072306.GA12834@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 06, 2020 at 08:23:06AM +0100, Christoph Hellwig wrote: > If people want to use the "raw" IOMMU API with not cache coherent > devices we'll need a cache maintainance API that goes along with it. > It could either be formally part of the IOMMU API or be separate. The IOMMU-API does not care about the caching effects of DMA, is manages IO address spaces for devices. I also don't know how this would be going to be implemented, the IOMMU-API does not have the concept of handles for mapped ranges and does not care about CPU virtual addresses (which are needed for cache flushes) of the memory it maps into IO page-tables. So I think a cache management API should be separate from the IOMMU-API. Regards, Joerg