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=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable 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 A2447C4708F for ; Wed, 2 Jun 2021 08:12:58 +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 6618A613CA for ; Wed, 2 Jun 2021 08:12:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6618A613CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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.20210309; 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:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xvDgn8zZcosjjPRTuN/D1sueNA/pS6JhQ2/a2BAL0/o=; b=Yl1mi3lg/bPLS9 s+Fq9w4gXgrqjbmX2mVncpLg1tGCbxEpNbSuRxeeIt4cvlzapxB0EMwbpr+QUr972/vMjNgaladby M2o55244igWNyQU5zYXtbp1LisHUBadofhgaP4KdCJqOsbobQgnHK/5aY5YjcxLcBMDHc5VAJ3J2R p0UH2qmAh3mGolwEtuLCrUeTaIiKMIBwegwOvO9SYS49bJjhdTRgyAxO4Aw4pNhbQWrrKs8C1puT6 11Ln+rgq9ZHuQu0zSBmnnS2IbliiY8hNfEsV7bD0g3dZuPp6YD3/2rWT6XBn9U16HlEw4lMuvCxJ7 6tSkpuCgZeyih8FjtJJg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1loLxn-002Wfs-8e; Wed, 02 Jun 2021 08:10:56 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1loLO5-002KgS-1l for linux-arm-kernel@lists.infradead.org; Wed, 02 Jun 2021 07:34:03 +0000 Received: from mail-wr1-f71.google.com ([209.85.221.71]) by youngberry.canonical.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1loLO1-0002BG-GV for linux-arm-kernel@lists.infradead.org; Wed, 02 Jun 2021 07:33:57 +0000 Received: by mail-wr1-f71.google.com with SMTP id g3-20020adfd1e30000b02901122a4b850aso627721wrd.20 for ; Wed, 02 Jun 2021 00:33:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HClBKpLS3bvtISBUHHdtztmkoTHT8tlXWF46fhCiu1Q=; b=TYgE4UmpwIfATP2gcdUhgeZNyMPt8i9Q/sgYjHPvr7OgPnGwM0IVpM2ZvuyN0G9fss oP0NEjLXs6eBg3Mtph9vJZzuHubUiYYfEZoDqSCZekpKiOLZnZvfJ3XpWodYx38FEamM jWQlE/70J4IT1d0AiHy2fnwztoOHqMK/+hTpSbnpWZ/P1b5tYhLcTH/SWNqrN/Dz7sj3 zaPnPgyDoHXL3Ap0P/HS5gm7q0vbfkt1Lbgw4YcntUXt/8tiMdqMMvjFrtdGX6QDTQNx A0LlQMyyHaarY/CVOLYgd9X9G4N31RPioMuIGMAXYpQo1r3VYpMpeQNwpYnUebnkjKEY OiHw== X-Gm-Message-State: AOAM5338cdAiECWIFayqXLqFCYJ8GBobtXRXMHtp77EAeW2SF6K5wJ1N MItd7QPLognTC0ANriq4z3iJyX4cDnrdMCfvsqjYa+KU6Vemq3DIV7lHNKr2i4hyMkLPT17dfJY NksjbcW7LqW2Sb8yKO68CYpuB1oYMFN5FWia6nn9mk0l7N0gEP+ot X-Received: by 2002:a05:6000:148:: with SMTP id r8mr32414882wrx.311.1622619237000; Wed, 02 Jun 2021 00:33:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzQnkoWybqGMGj8ENL2S2XqXPqgS4+4lked9VnSF0GzYamJSAhJ9ADYFKXpPvIHGeavGwK6FQ== X-Received: by 2002:a05:6000:148:: with SMTP id r8mr32414863wrx.311.1622619236848; Wed, 02 Jun 2021 00:33:56 -0700 (PDT) Received: from [192.168.1.115] (xdsl-188-155-185-9.adslplus.ch. [188.155.185.9]) by smtp.gmail.com with ESMTPSA id x10sm5671551wrt.65.2021.06.02.00.33.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Jun 2021 00:33:56 -0700 (PDT) Subject: Re: [PATCH v2 00/10] arm64: tegra: Prevent early SMMU faults To: Thierry Reding , Will Deacon References: <20210420172619.3782831-1-thierry.reding@gmail.com> <20210601122646.GB27832@willie-the-truck> From: Krzysztof Kozlowski Message-ID: <6826d892-d1ac-e3b1-ebee-68392d11d7c5@canonical.com> Date: Wed, 2 Jun 2021 09:33:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210602_003401_296416_E17F687C X-CRM114-Status: GOOD ( 35.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: , Cc: Joerg Roedel , iommu@lists.linux-foundation.org, Jon Hunter , Nicolin Chen , linux-tegra@vger.kernel.org, Robin Murphy , linux-arm-kernel@lists.infradead.org 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 On 01/06/2021 20:08, Thierry Reding wrote: > On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote: >> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote: >>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote: >>>> From: Thierry Reding >>>> >>>> Hi, >>>> >>>> this is a set of patches that is the result of earlier discussions >>>> regarding early identity mappings that are needed to avoid SMMU faults >>>> during early boot. >>>> >>>> The goal here is to avoid early identity mappings altogether and instead >>>> postpone the need for the identity mappings to when devices are attached >>>> to the SMMU. This works by making the SMMU driver coordinate with the >>>> memory controller driver on when to start enforcing SMMU translations. >>>> This makes Tegra behave in a more standard way and pushes the code to >>>> deal with the Tegra-specific programming into the NVIDIA SMMU >>>> implementation. >>>> >>>> Compared to the original version of these patches, I've split the >>>> preparatory work into a separate patch series because it became very >>>> large and will be mostly uninteresting for this audience. >>>> >>>> Patch 1 provides a mechanism to program SID overrides at runtime. Patch >>>> 2 updates the ARM SMMU device tree bindings to include the Tegra186 >>>> compatible string as suggested by Robin during review. >>>> >>>> Patches 3 and 4 create the fundamentals in the SMMU driver to support >>>> this and also make this functionality available on Tegra186. Patch 5 >>>> hooks the ARM SMMU up to the memory controller so that the memory client >>>> stream ID overrides can be programmed at the right time. >>>> >>>> Patch 6 extends this mechanism to Tegra186 and patches 7-9 enable all of >>>> this through device tree updates. Patch 10 is included here to show how >>>> SMMU will be enabled for display controllers. However, it cannot be >>>> applied yet because the code to create identity mappings for potentially >>>> live framebuffers hasn't been merged yet. >>>> >>>> The end result is that various peripherals will have SMMU enabled, while >>>> the display controllers will keep using passthrough, as initially set up >>>> by firmware. Once the device tree bindings have been accepted and the >>>> SMMU driver has been updated to create identity mappings for the display >>>> controllers, they can be hooked up to the SMMU and the code in this >>>> series will automatically program the SID overrides to enable SMMU >>>> translations at the right time. >>>> >>>> Note that the series creates a compile time dependency between the >>>> memory controller and IOMMU trees. If it helps I can provide a branch >>>> for each tree, modelling the dependency, once the series has been >>>> reviewed. >>>> >>>> Changes in v2: >>>> - split off the preparatory work into a separate series (that needs to >>>> be applied first) >>>> - address review comments by Robin >>>> >>>> Thierry >>>> >>>> Thierry Reding (10): >>>> memory: tegra: Implement SID override programming >>>> dt-bindings: arm-smmu: Add Tegra186 compatible string >>>> iommu/arm-smmu: Implement ->probe_finalize() >>>> iommu/arm-smmu: tegra: Detect number of instances at runtime >>>> iommu/arm-smmu: tegra: Implement SID override programming >>>> iommu/arm-smmu: Use Tegra implementation on Tegra186 >>>> arm64: tegra: Use correct compatible string for Tegra186 SMMU >>>> arm64: tegra: Hook up memory controller to SMMU on Tegra186 >>>> arm64: tegra: Enable SMMU support on Tegra194 >>>> arm64: tegra: Enable SMMU support for display on Tegra194 >>>> >>>> .../devicetree/bindings/iommu/arm,smmu.yaml | 11 +- >>>> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 4 +- >>>> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 166 ++++++++++++++++++ >>>> drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3 +- >>>> drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c | 90 ++++++++-- >>>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 13 ++ >>>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 + >>>> drivers/memory/tegra/mc.c | 9 + >>>> drivers/memory/tegra/tegra186.c | 72 ++++++++ >>>> include/soc/tegra/mc.h | 3 + >>>> 10 files changed, 349 insertions(+), 23 deletions(-) >>> >>> Will, Robin, >>> >>> do you have any more comments on the ARM SMMU bits of this series? If >>> not, can you guys provide an Acked-by so that Krzysztof can pick this >>> (modulo the DT patches) up into the memory-controller tree for v5.14? >>> >>> I'll send out a v3 with the bisectibilitiy fix that Krishna pointed >>> out. >> >> Probably best if I queue 3-6 on a separate branch once you send a v3, >> then Krzysztof can pull that in if he needs it. > > Patch 5 has a build-time dependency on patch 1, so they need to go in > together. The reason why I suggested Krzysztof pick these up is because > there is a restructuring series that this depends on, which will go into > Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other > and mostly unrelated stuff as well. I missed that part... what other series are needed for this one? Except Dmitry's power management set I do not have anything in my sight for Tegras memory controllers. Anyway, I can take the memory bits and provide a stable tag with these. Recently there was quite a lot work around Tegra memory controllers, so this makes especially sense if new patches appear. > > Alternatively I can set this all up on stable branches and send out pull > requests for both you and Krzysztof to merge. Or if this is all too > complicated and you'd just prefer to ack the patches I could also take > this through ARM SoC via the Tegra tree. > > Thierry > Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel