Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp1704909pxy; Mon, 2 Aug 2021 08:16:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGyd+/CjXwCOrdktWMl2Y7qzTtOY/Dsak7k9MpH+xbOpaoUwzC+dZOzxc9WRAdIglcxerQ X-Received: by 2002:a17:906:d101:: with SMTP id b1mr15652659ejz.424.1627917374657; Mon, 02 Aug 2021 08:16:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627917374; cv=none; d=google.com; s=arc-20160816; b=O7lgCcCwOaET/tG69gxtP8eOjZZlJB6c081abtABi7OaDnJM64MvcHrOcv1lRnr/vB yThok4ZvbOo0/KP+C9krudfOw2uje/kUie44r8xLc0vDZURWeXLdz8CDnhO6PaFVqxnc 3oIG+LIc5M4XBuwGlsQXQT95CYWSCYydHH0mrmEEj/PNqR5mHS0ZiQ7hUJ3E1JGorYSW x8j+nmUlAkElkzwL5hPc5vjF/rMLRc6eo+H9uhVwCcfqYsgXIw1ELwlZ3XFImC7xwANH FM2HpjB9fTLIGnNY159zPrkEMb8BGDPfvQHOxabPDU7ZcJG1Xp5oTEtxgV1t0luHVP7G B7/g== 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=5S/KASQ9yeLiS0+3yYcSmQ1e90AFhCzMnzWVj1bHuAc=; b=usuNxeJI/Co50ylYP3S/JPi2jk5jG+Fa1uPn1V1PUsqa6+TfmVy0JlTx7Bc6IDSUN8 pr7E+YaaV91HMa6kYqDIp4lfPUDEORp+YDYi3CSk64rZSxw4xqXeCdDIqduh2G3/W+zB BJC5Y8Fmi5YHFfsuGI0UxQdBUOaPg/3WN3+R+rcQaOk6aBEPiAnaALVAXFqeUxDkgtaY jngYmj2GDrJplCrxNSma5pOh9i4I1M8+tsv+tV1bAqKYNliUz/IXIDYQuUI/uopT/eSW rfOZqCLPPx3UxhmVQNyUE0IV6ekBB24IOtYWNg6l/se+VnCA4DxHKmYNnN9RzF2AYfCd AMMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=I+L+PP6a; 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 o13si9876922ejm.0.2021.08.02.08.15.43; Mon, 02 Aug 2021 08:16:14 -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=I+L+PP6a; 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 S234431AbhHBPOZ (ORCPT + 99 others); Mon, 2 Aug 2021 11:14:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:34526 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234508AbhHBPOZ (ORCPT ); Mon, 2 Aug 2021 11:14:25 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 1C9C160FF2; Mon, 2 Aug 2021 15:14:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1627917255; bh=UYOjm0eFhgR8EvFjQmM1ln8mHCxXRZCUDUqH/Bvbfyc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=I+L+PP6a5jTfzy3P7sMw1ozlawfViMsG4K1XbMXEN7FNMylVLZukn49Or+IvXjCFf vMw+jdh/BQgBnP9wNdZTsPb45W6h9jdnesphww0jMhHlT2zxHkQuOmRbK2W6OcpnrV XFbMBWrApX6RisQX8Meh9WBAddgraG1S8IK5FEufYZw6Sm9zaF68fW176PXqIj266L yG8Mc8wLP/Xmk2gtV9MIgbmfbXoe8E5XdKdDFIsApjuPza4bI/jK1KJXyIDyS44XJN mi0nYqjnKPxx44IFD3m4coN8gQDZOhB9FLfNIfPMHSgXy3CZUFvmibAwxdcGxAAq/p cLmIeXXFw8p3Q== Date: Mon, 2 Aug 2021 16:14:09 +0100 From: Will Deacon To: Rob Clark Cc: Sai Prakash Ranjan , Georgi Djakov , "Isaac J. Manjarres" , David Airlie , Akhil P Oommen , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Linux Kernel Mailing List , Sean Paul , Jordan Crouse , Kristian H Kristensen , dri-devel , Daniel Vetter , linux-arm-msm , freedreno , Robin Murphy , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Subject: Re: [Freedreno] [PATCH 0/3] iommu/drm/msm: Allow non-coherent masters to use system cache Message-ID: <20210802151409.GE28735@willie-the-truck> References: <20210728140052.GB22887@mms-0441> <8b2742c8891abe4fec3664730717a089@codeaurora.org> <20210802105544.GA27657@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 02, 2021 at 08:08:07AM -0700, Rob Clark wrote: > On Mon, Aug 2, 2021 at 3:55 AM Will Deacon wrote: > > > > On Thu, Jul 29, 2021 at 10:08:22AM +0530, Sai Prakash Ranjan wrote: > > > On 2021-07-28 19:30, Georgi Djakov wrote: > > > > On Mon, Jan 11, 2021 at 07:45:02PM +0530, Sai Prakash Ranjan wrote: > > > > > commit ecd7274fb4cd ("iommu: Remove unused IOMMU_SYS_CACHE_ONLY flag") > > > > > removed unused IOMMU_SYS_CACHE_ONLY prot flag and along with it went > > > > > the memory type setting required for the non-coherent masters to use > > > > > system cache. Now that system cache support for GPU is added, we will > > > > > need to set the right PTE attribute for GPU buffers to be sys cached. > > > > > Without this, the system cache lines are not allocated for GPU. > > > > > > > > > > So the patches in this series introduces a new prot flag IOMMU_LLC, > > > > > renames IO_PGTABLE_QUIRK_ARM_OUTER_WBWA to IO_PGTABLE_QUIRK_PTW_LLC > > > > > and makes GPU the user of this protection flag. > > > > > > > > Thank you for the patchset! Are you planning to refresh it, as it does > > > > not apply anymore? > > > > > > > > > > I was waiting on Will's reply [1]. If there are no changes needed, then > > > I can repost the patch. > > > > I still think you need to handle the mismatched alias, no? You're adding > > a new memory type to the SMMU which doesn't exist on the CPU side. That > > can't be right. > > > > Just curious, and maybe this is a dumb question, but what is your > concern about mismatched aliases? I mean the cache hierarchy on the > GPU device side (anything beyond the LLC) is pretty different and > doesn't really care about the smmu pgtable attributes.. If the CPU accesses a shared buffer with different attributes to those which the device is using then you fall into the "mismatched memory attributes" part of the Arm architecture. It's reasonably unforgiving (you should go and read it) and in some cases can apply to speculative accesses as well, but the end result is typically loss of coherency. Will