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=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS 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 2E27CC433E0 for ; Sun, 5 Jul 2020 03:39:35 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 E8F4920890 for ; Sun, 5 Jul 2020 03:39:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hZ52yqn5"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="O2lLgZzc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8F4920890 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org 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=merlin.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=QLAzk4Z8rQdze0Gfw7qLaAga6GRuatm9anVtUnWZPv4=; b=hZ52yqn5gALxjNvc3wRZwqHFv wRZ5iIJr8Rmra4zc5nrx8uiGrlqlZETGRA4tkwpAq5quYef/tIa9IZdTYgD8OOryuvbgjxgsc2JeN p/WNWSand0RsYeKr+YCHZySEcF7CcRWV6z5eqSfEALf5cjZeH8jdH+lPT2Dx8znmS15xL/YHNkYR8 beZIHEW7rhELPt7FW2kFpNFFukl7ur3zF+LAWzgylxNT2/5LCcRhIu+igCa3nO7eK4X6CXnivhSn0 NikEEhpDtfyW758XwTLntFWxszj1889+nay3Na7EnsZnNVI0aj0unW+CcKjZy/bFsFV2ZVFMgiI2I PWUON+60w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jrvTL-0007Ea-Ul; Sun, 05 Jul 2020 03:37:43 +0000 Received: from mail-pl1-x643.google.com ([2607:f8b0:4864:20::643]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jrvTI-0007Dp-NM for linux-arm-kernel@lists.infradead.org; Sun, 05 Jul 2020 03:37:42 +0000 Received: by mail-pl1-x643.google.com with SMTP id g17so14026646plq.12 for ; Sat, 04 Jul 2020 20:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=M5ZbztlPkvw+9ErJFWw7Qbat+ZkMk081NbvPHaI46hs=; b=O2lLgZzcbDRX8J92t5mKKUYXAwjo/sQXHSA3N7D4uuiEl8hO5WSoR/nmtz3zSlJyNz H4tFAx0OhM+bYW5A2+HaVgdhP8n38fXZCTnw9ok2Aahub5NKT/tgPW+8b/SMC7izclFy gYj2DhmS110EYhViIceJGIaX4DZMUPJkhNJ7o/feDHm78xBYlGfwCtuEq/mI08PXg5SN e7GCRB0oJVvxKxFFy1DmJpa1rNquJg9FjMhmetGE81blw8bV6lsReGYMclOJpkdYsX8S K8RbC0lFNrxBmYqQ9u2xuG964lHJL/qmc87VxTU6jwr5pmEiyqB01/PYLWoRyl/lHG8C bamA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=M5ZbztlPkvw+9ErJFWw7Qbat+ZkMk081NbvPHaI46hs=; b=MJOnrR7CiQAKrvtzD6I7Nq73anFu3sQjkYeBjMD9/D/99pFVoNMgWmskvZHyaalDdf aVqYrrxxIKHAU/DAwSYHaKKU4JhsAesdlXlwtTaME32cnALeO1rPzH/JEBWkSxyCRsBW wjnaSicenaxnp9KbJRDmJPxEj3e7narAf0I+wDlIUM11/cZdlYKnOyuuQ+ORiLuBLSEt NU0sunkQ5idAslYXrUDE0fOaOYZZxUwKM/trq9Ex0Sr3KSDsvtFU1XOWzMcwdw2w2gXX H2WBrT3JHxi1u0nCkbM3rnm4duN7CqDzEZKVbh9wGGWj/YTcjoAdWWW+eaG1vWlCgLjd hpKw== X-Gm-Message-State: AOAM531aCsCx1bKV11esAiGuQbmvdwvuiBKkKd5eqPBJN9xNlfY6U4I5 sQOeQIyJuil3Tr54CQG0r9osTg== X-Google-Smtp-Source: ABdhPJwYJ4bAkZPeI8sSzaQN9k6F5rcjd5JMGeKP/JEQ+CUkkHSBMoFuFc3gUDQ0nwnKd5YninLHog== X-Received: by 2002:a17:90a:db48:: with SMTP id u8mr14034064pjx.169.1593920255249; Sat, 04 Jul 2020 20:37:35 -0700 (PDT) Received: from builder.lan (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28]) by smtp.gmail.com with ESMTPSA id x10sm15766727pfp.80.2020.07.04.20.37.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jul 2020 20:37:34 -0700 (PDT) Date: Sat, 4 Jul 2020 20:35:11 -0700 From: Bjorn Andersson To: Will Deacon Subject: Re: [PATCH 1/1] iommu/arm-smmu: Implement qcom,skip-init Message-ID: <20200705033511.GR388985@builder.lan> References: <20200704122809.73794-1-konradybcio@gmail.com> <20200704130922.GB21333@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200704130922.GB21333@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200704_233741_145105_A357B355 X-CRM114-Status: GOOD ( 30.96 ) 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: devicetree@vger.kernel.org, jcrouse@codeaurora.org, skrzynka@konradybcio.pl, Joerg Roedel , Konrad Dybcio , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Rob Herring , john.stultz@linaro.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 Sat 04 Jul 06:09 PDT 2020, Will Deacon wrote: > [Adding Bjorn, Jordan and John because I really don't want a bunch of > different ways to tell the driver that the firmware is screwing things up] > Thanks Will. > On Sat, Jul 04, 2020 at 02:28:09PM +0200, Konrad Dybcio wrote: > > This adds the downstream property required to support > > SMMUs on SDM630 and other platforms (the need for it > > most likely depends on firmware configuration). > > > > Signed-off-by: Konrad Dybcio > > --- > > .../devicetree/bindings/iommu/arm,smmu.yaml | 10 ++++++++++ > > drivers/iommu/arm-smmu.c | 15 +++++++++------ > > 2 files changed, 19 insertions(+), 6 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > index d7ceb4c34423..9abd6d41a32c 100644 > > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml > > @@ -102,6 +102,16 @@ properties: > > access to SMMU configuration registers. In this case non-secure aliases of > > secure registers have to be used during SMMU configuration. > > > > + qcom,skip-init: > > + description: | > > + Disable resetting configuration for all context banks > > + during device reset. This is useful for targets where > > + some context banks are dedicated to other execution > > + environments outside of Linux and those other EEs are > > + programming their own stream match tables, SCTLR, etc. > > + Without setting this option we will trample on their > > + configuration. > > It would probably be better to know _which_ context banks we shouldn't > touch, no? Otherwise what happens to the others? > >From my investigations of the issue of maintaining the boot display through the initialization of arm-smmu I assume the reason for skipping this step don't want to flush out the SMR, S2CR and context bank initialization because it would disrupt the display hardware's access to memory. And in itself I believe that this is quite certainly going to work - until you start attaching devices. Because in itself this does nothing to ensure that the driver won't overwrite stream mapping or context bank configuration as devices are attached. So on e.g. SDM845 we need to ensure that the driver doesn't stomp over the display mapping left by the bootloader. Further more, on platforms such as QCS405 (which are derived from platforms supported by qcom_iommu today), the stream mapping registers (SMR and S2CR) are write ignore, which means that without knowledge about the existing mappings the hardware and driver will be out of sync. NB. Compared to the platforms that is supported by qcom_iommu, the stream mapping registers are readable on these newer platforms, while on e.g. MSM8916 we get an access violation by attempting to read SMR/S2CR. > > + > > stream-match-mask: > > $ref: /schemas/types.yaml#/definitions/uint32 > > description: | > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c > > index 243bc4cb2705..a5c623d4caf9 100644 > > --- a/drivers/iommu/arm-smmu.c > > +++ b/drivers/iommu/arm-smmu.c > > @@ -1655,13 +1655,16 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu) > > * Reset stream mapping groups: Initial values mark all SMRn as > > * invalid and all S2CRn as bypass unless overridden. > > */ > > - for (i = 0; i < smmu->num_mapping_groups; ++i) > > - arm_smmu_write_sme(smmu, i); > > > > - /* Make sure all context banks are disabled and clear CB_FSR */ > > - for (i = 0; i < smmu->num_context_banks; ++i) { > > - arm_smmu_write_context_bank(smmu, i); > > - arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_FSR, ARM_SMMU_FSR_FAULT); > > + if (!of_find_property(smmu->dev->of_node, "qcom,skip-init", NULL)) { > > + for (i = 0; i < smmu->num_mapping_groups; ++i) > > + arm_smmu_write_sme(smmu, i); > > + > > + /* Make sure all context banks are disabled and clear CB_FSR */ > > + for (i = 0; i < smmu->num_context_banks; ++i) { > > + arm_smmu_write_context_bank(smmu, i); > > + arm_smmu_cb_write(smmu, i, ARM_SMMU_CB_FSR, ARM_SMMU_FSR_FAULT); > > + } > > } > > Do we not need to worry about the SMRs as well? > I don't think we should skip the actual initialization, because to avoid strange side effects we need to ensure that the driver and hardware are in sync (either for specific streams/banks or for all of them). I've continued my work on supporting boot display on e.g. SDM845, based on Thierry's patches, but still have some unresolved corner cases to fully resolve - e.g. how to ensure that the display hardware's stream mapping survives the probe deferral of the display driver. Hopefully I will be able to post something in a few days. That said, there's a generation of platforms between MSM8916 (which we support using qcom_iommu) and SDM845 (which can run with arm-smmu). AngeloGioacchino proposed a series last year to extend the qcom_iommu to support these [1]. If SD630 falls in this category, or in the newer SDM845/SM8150 category I don't know. It would be quite interesting to hear more about the exact behaviors seems on SDM630, to see how we can support this as well. [1] https://lore.kernel.org/linux-arm-msm/20191001155641.37117-1-kholk11@gmail.com/ Regards, Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel