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 32049C678D4 for ; Tue, 7 Mar 2023 11:51:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230211AbjCGLvS (ORCPT ); Tue, 7 Mar 2023 06:51:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230286AbjCGLu7 (ORCPT ); Tue, 7 Mar 2023 06:50:59 -0500 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1B5351C8C for ; Tue, 7 Mar 2023 03:49:45 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id m6so16692546lfq.5 for ; Tue, 07 Mar 2023 03:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678189781; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8NLnfgcJkBrupO9VeOIsatAqwiLwPWa5rkw2fb5PnaE=; b=UYvQ5bO2RzR51Mh38ODTgBjtWo2rd01w2DzKJ+NpS1vMuXxsIZJk1UL0Y9tvMY/erS WdcNtewN6BoWBvzNWdC7D5OzAVWUwrl418t7qzmoVXLW7HeQHGUJUllTxOAxPKMuos/I FnEFJdlTkGoepl4EBTUDhWvpEm1hlggXZgbJrM2QDGjqMvK09RAhyBe4g/zdhhWeZs19 2H7fcl1zyhk9DpjhmRDIDtaXkwftLIFWTRPHIHuoKTmaWO3N6eMFm5Cla1kFSe7fPjxJ Tas0sI2JB1IcP++DNwbqE8ksYqoqgZh125kLDgfhq0VIpwRgE5vveM3yXSMv/dLCUqEN /+TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678189781; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8NLnfgcJkBrupO9VeOIsatAqwiLwPWa5rkw2fb5PnaE=; b=gFUZyRHBgP1wddc51bvaov88tGhrL79c0zGuN3BD4NzuCQs9zMeIZUxpGG+A2Ej2Se AJ2oA480BuDBN45g2ZnD1kai4OxvuwFCSZp8yxDP70hNrz/iiqeoMhvxMfs7Zsw6sSgf F1T2DEKozItcXNYMhFWSy25T+1DXkZ7VVPPaVqfeIkky+fpSMOPQWG4s3Ke2OywJ4R2T BAaHvIAO4fMsy/trqlHkSENesh2GCqguaIzNoldfoDUiuT7HDRokePxBXEBVadi0lUsw A1N2VkKXl2n+3XmWMRDwpiUDZE57GmFZW0EM3R3NYE/TdmuBmZl1FTau+6y7fjLYpLaX 4wEA== X-Gm-Message-State: AO0yUKW0EPSAqILrio3UznjykgTdUn82D8SRtTb+quxyUNzmEU1/+EXt 4lQhxGc3ZmoqwPmxMMUa2+dNeg== X-Google-Smtp-Source: AK7set820Wh82BGJ6Ihvrw7CYOrPuMDU5y9XvpQtW63tea7D4cxj+nT71DKMYqTpL9A9f0fzFll76w== X-Received: by 2002:ac2:558e:0:b0:4dc:852d:9b88 with SMTP id v14-20020ac2558e000000b004dc852d9b88mr3812252lfg.45.1678189781415; Tue, 07 Mar 2023 03:49:41 -0800 (PST) Received: from [10.10.15.130] ([192.130.178.91]) by smtp.gmail.com with ESMTPSA id j19-20020a19f513000000b004dc721ea6a1sm1997226lfb.273.2023.03.07.03.49.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Mar 2023 03:49:40 -0800 (PST) Message-ID: <47b591c0-2f68-429d-6d1b-fa8b701785ac@linaro.org> Date: Tue, 7 Mar 2023 13:49:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 7/8] arm64: dts: qcom: ipq9574: Add USB related nodes To: Varadarajan Narayanan Cc: Andy Gross , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Georgi Djakov References: <6b8d17006d8ee9a1b0c4df803c1cc7caf53ea3ef.1677749625.git.quic_varada@quicinc.com> <61e8c730-e46d-728d-d770-f1ead4405d12@quicinc.com> <83184da4-b183-3271-983f-3a1a62fb9f1a@linaro.org> <365f2609-d3b4-df23-5b6e-7a190815a640@quicinc.com> Content-Language: en-GB From: Dmitry Baryshkov In-Reply-To: <365f2609-d3b4-df23-5b6e-7a190815a640@quicinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 07/03/2023 08:36, Varadarajan Narayanan wrote: > > On 3/6/2023 5:21 PM, Dmitry Baryshkov wrote: >> On 06/03/2023 13:26, Varadarajan Narayanan wrote: >>> Dmitry, >>> >>> On 3/2/2023 9:52 PM, Dmitry Baryshkov wrote: >>>> On Thu, 2 Mar 2023 at 11:57, Varadarajan Narayanan >>>> wrote: >>>>> Add USB phy and controller related nodes >>>>> >>>>> Signed-off-by: Varadarajan Narayanan >>>>> --- >>>>>   arch/arm64/boot/dts/qcom/ipq9574.dtsi | 92 >>>>> +++++++++++++++++++++++++++++++++++ >>>>>   1 file changed, 92 insertions(+) >>>>> >>>>> diff --git a/arch/arm64/boot/dts/qcom/ipq9574.dtsi >>>>> b/arch/arm64/boot/dts/qcom/ipq9574.dtsi >>>>> index 2bb4053..319b5bd 100644 >>>>> --- a/arch/arm64/boot/dts/qcom/ipq9574.dtsi >>>>> +++ b/arch/arm64/boot/dts/qcom/ipq9574.dtsi >> >> [skipped] >> >> >>>>> +               usb3: usb3@8A00000 { >>>> You know the drill. This node is in the wrong place. >>>> >>>>> +                       compatible = "qcom,dwc3"; >>>>> +                       reg = <0x8AF8800 0x400>; >>>>> +                       #address-cells = <1>; >>>>> +                       #size-cells = <1>; >>>>> +                       ranges; >>>>> + >>>>> +                       clocks = <&gcc GCC_SNOC_USB_CLK>, >>>>> +                               <&gcc GCC_ANOC_USB_AXI_CLK>, >>>>> +                               <&gcc GCC_USB0_MASTER_CLK>, >>>>> +                               <&gcc GCC_USB0_SLEEP_CLK>, >>>>> +                               <&gcc GCC_USB0_MOCK_UTMI_CLK>; >>>>> + >>>>> +                       clock-names = "sys_noc_axi", >>>>> +                               "anoc_axi", >>>>> +                               "master", >>>>> +                               "sleep", >>>>> +                               "mock_utmi"; >>>> Please fix the indentation of the lists. >>>> >>>>> + >>>>> +                       assigned-clocks = <&gcc GCC_SNOC_USB_CLK>, >>>>> +                                         <&gcc GCC_ANOC_USB_AXI_CLK>, >>>> Why do you assign clock rates to the NOC clocks? Should they be set >>>> using the interconnect instead? >>> >>> The SNOC and ANOC run at a fixed speed of 350MHz and 342MHz >>> respectively and are not scaled. These clocks are for the interface >>> between the USB block and the SNOC/ANOC. Do we still need to use >>> interconnect? >> >> Maybe I misunderstand something here. If the snoc and anoc speeds are >> at 350 MHz and 342 MHz, why do you assign clock-rates of 200 MHz? >> >> Is it enough to call clk_prepare_enable() for these clocks or the rate >> really needs to be set? > > The rate of 200MHz is not being set for the SNOC/ANOC. It is for the > NIU that connects the USB and SNOC/ANOC. The reason for setting the > rate to 200MHz is to configure the RCG parent for these interface > clocks. That said can we configure this RCG standalone in the driver > and enable these clocks? We discussed this separately with Georgi Djakov. Let me quote his IRC message: "it sounds like this is for USB port that connects to the NOC. if bandwidth scaling is not needed (or other interconnect configuration), then maybe this can go without interconnect provider driver." However as we discover more and more about this platform (e.g. PCIe using the aggre_noc region to setup some magic registers, see [1]), I'm more and more biased towards suggesting implementing the interconnect driver to setup all these tiny little things. With the DT tree being an ABI, it is much preferable to overestimate the needs rather than underestimating them (and having to cope with the backwards compatibility issues). Generally I think that PCIe/USB/whatever should not poke into NoC registers or NoC/NIU clocks directly (because this is a very platform-specific item). Rather than that it should tell the icc/opp/whatever subsystem, "please configure the SoC for me to work". [1] https://lore.kernel.org/linux-arm-msm/30cf9717-dcca-e984-c506-c71b7f8e32cd@quicinc.com/ > > Thanks > Varada > > >> >> >>> >>>>> + <&gcc GCC_USB0_MASTER_CLK>, >>>>> +                                         <&gcc >>>>> GCC_USB0_MOCK_UTMI_CLK>; >>>>> +                       assigned-clock-rates = <200000000>, >>>>> + <200000000>, >>>>> + <200000000>, >>>>> + <24000000>; >>>>> + >>>>> +                       resets = <&gcc GCC_USB_BCR>; >>>>> +                       status = "disabled"; >>>>> + >>>>> +                       dwc_0: dwc3@8A00000 { >>>>> +                               compatible = "snps,dwc3"; >>>>> +                               reg = <0x8A00000 0xcd00>; >>>>> +                               clock-names = "ref"; >>>>> +                               clocks = <&gcc >>>>> GCC_USB0_MOCK_UTMI_CLK>; >>>> clocks before clock-names >>>> >>>>> + interrupts = ; >>>>> +                               phys = <&qusb_phy_0>, <&usb0_ssphy>; >>>>> +                               phy-names = "usb2-phy", "usb3-phy"; >>>>> +                               tx-fifo-resize; >>>>> +                               snps,dis_ep_cache_eviction; >>>>> +                               snps,is-utmi-l1-suspend; >>>>> +                               snps,hird-threshold = /bits/ 8 <0x0>; >>>>> +                               snps,dis_u2_susphy_quirk; >>>>> +                               snps,dis_u3_susphy_quirk; >>>>> + snps,quirk-frame-length-adjustment = <0x0A87F0A0>; >>>>> +                               dr_mode = "host"; >>>>> +                       }; >>>>> +               }; >>>>> + >>>>>                  pcie0_phy: phy@84000 { >>>>>                          compatible = >>>>> "qcom,ipq9574-qmp-gen3x1-pcie-phy"; >>>>>                          reg = <0x00084000 0x1bc>; /* Serdes PLL */ >>>>> -- >>>>> 2.7.4 >>> >>> Will address these and post a new revision. >>> >>> Thanks >>> >>> Varada >>> >> -- With best wishes Dmitry