Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3525073pxt; Tue, 10 Aug 2021 05:49:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKR+9Bk93HpjPBMGc+BHoMo8cUUTQwmyxjgEjdvEsPC9jyFd1VIV+5bNikRkmB//0aZ44Q X-Received: by 2002:a17:907:2b09:: with SMTP id gc9mr13681558ejc.49.1628599746100; Tue, 10 Aug 2021 05:49:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628599746; cv=none; d=google.com; s=arc-20160816; b=CN1k85wMXAC22GAsopRLDoNGQzbnqDN8lyLzBr3KERDGE4prG+yYbdF/Ic5rBgpXB1 J9EaP2GR7q048AV8FuRKkNOAhGn5Gv9qJVoirKa0T/ZAd8JD2C6ZavSCCkjq8en76L/y +Iy66tMowrspvtRnQ/uBe67ceYJw8JVOFgMzUAzPTsG5uQZq27bExMpc9upXJSJ/VUH5 p0Qgd8ZPcCrbRzWajDwVaPLt2JGoswY4vLJoS7O5u65ians6z3UAeDYqYxCD0GybLXFu AhsYApoot7SWxq7doUbJFdoWHxnsykaxie1ro+2Cg8lHJ9+XMZS6xGlFLtt0S0sWmA0e 7QrQ== 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 :dkim-signature; bh=x9PNw7GLnwjiADn4oxadBZSaGbZr47aWB0DejhJysik=; b=BQlgsBDwiZm8C3VZqwsp/n0jVA/dTQA/ctX4/a03smZSql3wquxDbbG3aFKFUEN9W+ bYl7vSegPWrKbKqAtVmGIWWPzBgnnsd0ztx44MNDsM+ePKxOctrP1f+7GjFi3v3mql38 GeusSYONkdTvJkmo28+9rq/PVnufOt+Y1KFnO+tMkz0oDJkC/6UB2zmA3A9SD7kXLbwf UJRqNqiRm76XWWK+8yH1trDhtmbbZoE7Ljw5o8T8hXWDaCe4Wdi/oTDrGqKgZrqKhP4Y 6HE1lFG4DbZeLrYhCFvhUvMbOg88CZGMWxqUB+Nf+FEB/eBdjLU13zVyetxjdoSX3/95 6h2Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mOAHGE6m; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gf2si21154305ejb.500.2021.08.10.05.48.41; Tue, 10 Aug 2021 05:49:06 -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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mOAHGE6m; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238770AbhHJJQu (ORCPT + 99 others); Tue, 10 Aug 2021 05:16:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:47934 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238745AbhHJJQr (ORCPT ); Tue, 10 Aug 2021 05:16:47 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id F3C166056B; Tue, 10 Aug 2021 09:16:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1628586986; bh=hG1PKIfUobySTRl3kToyKQWcPI+bWs/Llfdg4HtV8Lc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mOAHGE6mrYyzdYOiATqBh3ctWbADLleThoclue/CxW6EWM3taq8sQYiRgsVZlnr09 pTsO2mPLnhhPRbGIXVu+JQJ2eRglxQu799oybVa190XqsKer2qr7WDXFO6on/S0RdX rcaqL3+aDwZeiOVHzyEQ/0bEATuepbIqh1CLsdxN/hNFhyRgjwfkEBZW+iEoIap9QV Gx8IBDY7U01l8JCBcG53fyX1QSncT2DWzpjXp4GoKw3IIKzCKbj/Cy16Vee4V4RCDg +Y0VAfWigUKKCWw/eJynPJN7yEgpHxV4zOqqDEZ+BI+3XY4Utiq060cAGEHVTTGNQv PykOiqiyVk43A== Date: Tue, 10 Aug 2021 10:16:19 +0100 From: Will Deacon To: Sai Prakash Ranjan Cc: Rob Clark , "Isaac J. Manjarres" , freedreno , Jordan Crouse , David Airlie , linux-arm-msm , Akhil P Oommen , dri-devel , Linux Kernel Mailing List , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Kristian H Kristensen , Daniel Vetter , Sean Paul , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Robin Murphy Subject: Re: [Freedreno] [PATCH 0/3] iommu/drm/msm: Allow non-coherent masters to use system cache Message-ID: <20210810091619.GA2494@willie-the-truck> References: <20210802105544.GA27657@willie-the-truck> <20210802151409.GE28735@willie-the-truck> <20210809145651.GC1458@willie-the-truck> <20210809170508.GB1589@willie-the-truck> <20210809174022.GA1840@willie-the-truck> <76bfd0b4248148dfbf9d174ddcb4c2a2@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76bfd0b4248148dfbf9d174ddcb4c2a2@codeaurora.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 09, 2021 at 11:17:40PM +0530, Sai Prakash Ranjan wrote: > On 2021-08-09 23:10, Will Deacon wrote: > > On Mon, Aug 09, 2021 at 10:18:21AM -0700, Rob Clark wrote: > > > On Mon, Aug 9, 2021 at 10:05 AM Will Deacon wrote: > > > > On Mon, Aug 09, 2021 at 09:57:08AM -0700, Rob Clark wrote: > > > > > But I suppose we could call it instead IOMMU_QCOM_LLC or something > > > > > like that to make it more clear that it is not necessarily something > > > > > that would work with a different outer level cache implementation? > > > > > > > > ... or we could just deal with the problem so that other people can reuse > > > > the code. I haven't really understood the reluctance to solve this properly. > > > > > > > > Am I missing some reason this isn't solvable? > > > > > > Oh, was there another way to solve it (other than foregoing setting > > > INC_OCACHE in the pgtables)? Maybe I misunderstood, is there a > > > corresponding setting on the MMU pgtables side of things? > > > > Right -- we just need to program the CPU's MMU with the matching memory > > attributes! It's a bit more fiddly if you're just using ioremap_wc() > > though, as it's usually the DMA API which handles the attributes under > > the > > hood. > > > > Anyway, sorry, I should've said that explicitly earlier on. We've done > > this > > sort of thing in the Android tree so I assumed Sai knew what needed to > > be > > done and then I didn't think to explain to you :( > > > > Right I was aware of that but even in the android tree there is no user :) I'm assuming there are vendor modules using it there, otherwise we wouldn't have been asked to put it in. Since you work at Qualcomm, maybe you could talk to your colleagues (Isaac and Patrick) directly? > I think we can't have a new memory type without any user right in upstream > like android tree? Correct. But I don't think we should be adding IOMMU_* anything upstream if we don't have a user. Will