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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 812C4C433F5 for ; Tue, 12 Apr 2022 06:36:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349725AbiDLGiy (ORCPT ); Tue, 12 Apr 2022 02:38:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350561AbiDLGiM (ORCPT ); Tue, 12 Apr 2022 02:38:12 -0400 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6AE9017E35 for ; Mon, 11 Apr 2022 23:34:56 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id b21so3332780ljf.4 for ; Mon, 11 Apr 2022 23:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=O7aCx2FRRglqn4zVmoyWdyA60dbe6nn+Xs3q+BlzSm8=; b=L4yyc1O58czZqpyOXDLRpQ8l05yUbeItghn7To3S0DTazS9IDzRwjFvo5oGGj/Ls88 C4GOQKM/+5fkeRYDoXuhEmTXf1DxZnepoXvD/IF6VBHeRCUQJpjCBHfcuCcUVSJB54es /wKtWNYQY2589yuMTFIiRALHhdYyfernMdAAnT4qu61mOQHhoP4PJvJDoljAONcL+oAi trrCM5X5fB5mkiaJYdAe5vOzqScpL5sM9lIXGSMA4YbOFtf2OA8AUAgiT46HdZjjVEK4 AZRho6SWfHMRgAJdWxK5Gu9gQ6G1iqUGp2ODttg7nJK1v6LEEYNtnLGPDl0ECrNjXPzX 9k6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=O7aCx2FRRglqn4zVmoyWdyA60dbe6nn+Xs3q+BlzSm8=; b=VjbM2vwcnOWze5n942APdVaTLlTK7NYAuBSsY0QM2urPoeBZ81et3OpWw8RuGHzryw e9hwiCpfbNycRJCF/X5xxcYvMVcvmHYqyiefkdmmVQWm15d6bOUGuB0Y7Vnj8il4wpPQ d4ucGk+bW4gDx6HK1lC1sK0ikO1K7gzIf733SmY2m1mW4hu4qFoNW+7WOX++YOUqzwee 6t2HRIexN3B1dK+7UZ+/hsOJxNiPldqY82YstiO0dUu7WEVvAlmezXbudBPidm0Fvv1z NG7OdvT9uDP0u57OVgMiAS0eFjVq3EiXlGsEqEjuKJN1eO/tNTFE+b+i2clNnZev+Mmw ms+w== X-Gm-Message-State: AOAM532zdkgwPZdIxYoggOWEsxS9Knwjcpdd1gddjWSr3xxIg10iJqkW x2yTssrblq4CySv3Gwsnwf8Qmw== X-Google-Smtp-Source: ABdhPJz1jJQkcvdIMFi9xPEXuJ8UFT2G6hv/bmy3giVCY2SOU3WJ7AOgtzNN0L1E3q7f0TaLxs16tA== X-Received: by 2002:a2e:9ed7:0:b0:24b:369:538b with SMTP id h23-20020a2e9ed7000000b0024b0369538bmr23292287ljk.206.1649745294581; Mon, 11 Apr 2022 23:34:54 -0700 (PDT) Received: from [192.168.1.102] (88-113-46-102.elisa-laajakaista.fi. [88.113.46.102]) by smtp.gmail.com with ESMTPSA id bi2-20020a0565120e8200b004484aaaf818sm3541392lfb.13.2022.04.11.23.34.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Apr 2022 23:34:53 -0700 (PDT) Message-ID: <2af9a8a7-0904-df31-7c1a-21705bcda8d6@linaro.org> Date: Tue, 12 Apr 2022 09:34:31 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] arm64: dts: qcom: sm8450: fix interconnects property of UFS node Content-Language: en-US To: Bjorn Andersson , Dmitry Baryshkov Cc: Vinod Koul , Andy Gross , Rob Herring , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org References: <20220310221934.1560729-1-vladimir.zapolskiy@linaro.org> From: Vladimir Zapolskiy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Bjorn, On 4/12/22 05:35, Bjorn Andersson wrote: > On Tue 05 Apr 12:38 CDT 2022, Dmitry Baryshkov wrote: > >> On Tue, 5 Apr 2022 at 20:17, Bjorn Andersson wrote: >>> >>> On Tue 05 Apr 08:38 PDT 2022, Dmitry Baryshkov wrote: >>> >>>> On 11/03/2022 01:19, Vladimir Zapolskiy wrote: >>>>> All interconnect device tree nodes on sm8450 are 2-cells, however in >>>>> UFS node they are handled as 1-cells, fix it. >>>>> >>>>> Fixes: aa2d0bf04a3c ("arm64: dts: qcom: sm8450: add interconnect nodes") >>>>> Signed-off-by: Vladimir Zapolskiy >>>> >>>> Reviewed-by: Dmitry Baryshkov >>>> >>>> Bjorn, could you please this pick for the -rc kernel? >>>> >>> >>> The change is obviously correct, but what difference does this change >>> make with the current implementation? >> >> it makes interconnect paths probe correctly. All NoC have >> #interconnec-cells = <2> now. >> > > But there's no code in the UFS driver that calls of_icc_get(), so what > does this actually do? (Other than correcting the dtb for the day when > we add that support to the driver). FWIW the change also has a runtime effect, it fixes a parsing of the board dtb, otherwise a warning in the kernel log appears: OF: /soc@0/ufshc@1d84000: could not get #interconnect-cells for /clocks/sleep-clk Why /clocks/sleep-clk is mentioned here at all?? Its phandle value is 0x26, which is equal to SLAVE_UFS_MEM_CFG from the array. -- Best wishes, Vladimir >>>>> --- >>>>> arch/arm64/boot/dts/qcom/sm8450.dtsi | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi >>>>> index 0cd5af8c03bd..bbd38b55e976 100644 >>>>> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi >>>>> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi >>>>> @@ -1376,8 +1376,8 @@ ufs_mem_hc: ufshc@1d84000 { >>>>> iommus = <&apps_smmu 0xe0 0x0>; >>>>> - interconnects = <&aggre1_noc MASTER_UFS_MEM &mc_virt SLAVE_EBI1>, >>>>> - <&gem_noc MASTER_APPSS_PROC &config_noc SLAVE_UFS_MEM_CFG>; >>>>> + interconnects = <&aggre1_noc MASTER_UFS_MEM 0 &mc_virt SLAVE_EBI1 0>, >>>>> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_UFS_MEM_CFG 0>; >>>>> interconnect-names = "ufs-ddr", "cpu-ufs"; >>>>> clock-names = >>>>> "core_clk", >>>> >>>> >>>> -- >>>> With best wishes >>>> Dmitry >> >> >> >> -- >> With best wishes >> Dmitry