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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 65D3DC7EE2E for ; Fri, 9 Jun 2023 15:07:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xx6kEkuc3R+YGdboJDw/XqR6sK/wL4z1qSIvndWNdWM=; b=arpMfVzMgoBkEr IFBodGLgw/gt8DpocP/QZ4qCAINR1pxDq8BIbvrtR2S1rXFxJ+xi3GrEh33Y1KjBhejqEvDwPIGO4 09KUepRGxGmiSa1hOsxAZJF/qZ6oV3IiSIuxkOOjfSZtyK5RZvqtfprIyysgVt0Ce1c80oZfSC57z wErS3geujXFCvmyJJ7TJEKRLAYcIlW6GOLjErr0rK95OuXQT0PB3zlBTYFYHzfG6Es6f9iPW+UK3C x90QL8fdLpfwpbzLtnGGWkjDAkSPPB99UsHm59x/PJ2vNHDtfsj7YhHbyzLcEZvCVEqFt3Lz9Vhb3 787DJbJGUvDIh0Cp7w2w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q7dhz-00DNba-2L; Fri, 09 Jun 2023 15:07:23 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q7dhw-00DNaa-2e for linux-arm-kernel@lists.infradead.org; Fri, 09 Jun 2023 15:07:22 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0A043AB6; Fri, 9 Jun 2023 08:08:03 -0700 (PDT) Received: from [10.57.85.120] (unknown [10.57.85.120]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D5D833F663; Fri, 9 Jun 2023 08:07:14 -0700 (PDT) Message-ID: <54da68f0-9f9d-cea4-13fb-5e10b8171746@arm.com> Date: Fri, 9 Jun 2023 16:07:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH 0/3] arm64: dts: qcom: sa8775p: Add interconnect to SMMU Content-Language: en-GB To: Konrad Dybcio , Parikshit Pareek Cc: Will Deacon , Joerg Roedel , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Andy Gross , Bjorn Andersson , Manivannan Sadhasivam , Dmitry Baryshkov , Marijn Suijten , Adam Skladowski , linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev, devicetree@vger.kernel.org, "linux-kernel @ vger . kernel . org Prasanna Kumar" , Shazad Hussain References: <20230609054141.18938-1-quic_ppareek@quicinc.com> <79206b05-674b-1f6c-6eb1-ed45e6bd5637@linaro.org> <20230609125631.GA29252@hu-ppareek-blr.qualcomm.com> <2881f374-70e2-0057-f43e-7be12d32ae22@arm.com> From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230609_080720_906266_D7DDBD95 X-CRM114-Status: GOOD ( 16.01 ) 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2023-06-09 15:52, Konrad Dybcio wrote: > > > On 9.06.2023 16:45, Robin Murphy wrote: >> On 2023-06-09 13:56, Parikshit Pareek wrote: >>> On Fri, Jun 09, 2023 at 10:52:26AM +0200, Konrad Dybcio wrote: >>>> >>>> >>>> On 9.06.2023 07:41, Parikshit Pareek wrote: >>>>> Some qcom SoCs have SMMUs, which need the interconnect bandwidth to be >>>>> This series introduce the due support for associated interconnect, and >>>>> setting of the due interconnect-bandwidth. Setting due interconnect >>>>> bandwidth is needed to avoid the issues like [1], caused by not having >>>>> due clock votes(indirectly dependent upon interconnect bandwidth). >>>> >>>> [1] ??? >>> >>> My bad. Intended to mention following: >>> https://lore.kernel.org/linux-arm-msm/20230418165224.vmok75fwcjqdxspe@echanude/ >> >> This sounds super-dodgy - do you really have to rely on configuration of the interconnect path from the SMMU's pagetable walker to RAM to keep a completely different interconnect path clocked for the CPU to access SMMU registers? You can't just request the programming interface clock directly like on other SoCs? > On Qualcomm platforms, particularly so with the more recent ones, some > clocks are managed by various remote cores. Half of what the interconnect > infra does on these SoCs is telling one such core to change the internally > managed clock's rate based on the requested bw. That much I get, it just seems like an arse-backwards design decision if it's really necessary to pretend the SMMU needs to access memory in order for the CPU to be able to access the SMMU. The respective SMMU interfaces are functionally independent of each other - even if it is the case in the integration that both interfaces and/or the internal TCU clock do happen to be driven synchronously from the same parent clock - and in any sane interconnect the CPU->SMMU and SMMU->RAM routes would be completely different and not intersect at all. Thanks, Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel