Message ID | 20231227-topic-8280_pcie_dts-v1-2-13d12b1698ff@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-12296-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp1695709dyb; Wed, 27 Dec 2023 14:29:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IHY1p5U8CbKpTQIzxTCL0IFpfK6917FeZRgAQz7RYGq9zY3jWaF0mQJeO6FpOIY4I9iSzXI X-Received: by 2002:a05:6808:e87:b0:3b8:b063:5060 with SMTP id k7-20020a0568080e8700b003b8b0635060mr10380286oil.97.1703716175528; Wed, 27 Dec 2023 14:29:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703716175; cv=none; d=google.com; s=arc-20160816; b=nwe4u+du4ehEN+i8NvnJGbz0GWbYMsMvPtvR7TNGzLUNEwwOM7EwlUyWsp8ajjXPE7 NdIcXh8gTYXqf/9IwZ6ff7IjOxMA7lKtp8kFqHNLo6dOuxav4xNYfcwWKp2AdPUj7xxY VqZM7YccuyITypjHghgXnqcNVPWKvWWi/uhGYN/fhYIkLdUzI5ErPeNdjZjfsuNlx8VB MbdhhR3SuxqVzjxH0L94OZZk0O5qmJdfSwLIs6TYoB+gimvZbhvOYcwlb/sRT8rjscJ+ mr2mzXje1D4yf+1txFx5OYPI3eOE8e/9AQAGpC9OYaI5EeDt/ab8ty9tY1q+4qlMqk4o FN6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :subject:date:from:dkim-signature; bh=TOTPntAbgy3PGTrBl7b5lPQZPt4hEISp0YHsUMdQkVM=; fh=KLeS/c16yOJ1FS6Ho4w0J6IIxO2ziXCSDgX2W9R+at0=; b=HTnhvWOLM97wZ5RX88vqezVkXoFubi15AUMLxlQpa3AyXvjRMND7uMLM3H63pYVFPt kKr/WZFkPPYQGbt4+WivtsnjoZxMIgDrm1F4dEex8wckYkbjXwwHSvu5571N8aBIrdcL ir8MFSg4a06KUJV1kaYyECwa2Jusl6TGE4CIpx1I5V3Sgtc3Eu+sG0VKutOZ1WJPaodg 9F4FULp83F8vMW8RhRak5q9MSgNpyhsEayHND9Q75p1OXph813/OlGmZsQB6S+Y0ai/s CtW5ZO15h9DSvs4W3yhQCxiL9oPnRhcTDsNAzZcIWEn48U1/8HDwCelCInlN9CMcGzCs iTTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="y/1G+ZkL"; spf=pass (google.com: domain of linux-kernel+bounces-12296-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-12296-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id qp29-20020a05620a389d00b007815c8089c1si2774640qkn.99.2023.12.27.14.29.35 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Dec 2023 14:29:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-12296-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="y/1G+ZkL"; spf=pass (google.com: domain of linux-kernel+bounces-12296-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-12296-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 504BC1C210BC for <ouuuleilei@gmail.com>; Wed, 27 Dec 2023 22:29:35 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 50A9F4AF67; Wed, 27 Dec 2023 22:28:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="y/1G+ZkL" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 428BC498B2 for <linux-kernel@vger.kernel.org>; Wed, 27 Dec 2023 22:28:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-50e67e37661so5171094e87.0 for <linux-kernel@vger.kernel.org>; Wed, 27 Dec 2023 14:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1703716114; x=1704320914; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=TOTPntAbgy3PGTrBl7b5lPQZPt4hEISp0YHsUMdQkVM=; b=y/1G+ZkLNtycsSFhItAY+ChHXfVzhDzHBQyyZC7DpRU2ZpViK3G4G4F7uqzcN5BWkq ZLUHSE8dIhTOx7dHWWw6V8d2K/4aPwDVo/KdRg1qe8NX4CHFNMQ9hgnVKZs73FYzTnM5 AjnjpKYKOKnmszsG/IQ5DJS1IYrL3oatfJ073TYxqZdxYiCdfegPVgRvFgTTuMOfv2y8 0rt1L5fgoGGVdfo3lHVWib10iLFmjfNCvXhHFCgichd0kF4vcNSvYcOVd8Xcxbjsbqdt CNFfQmhrEaKJApQSCxkD+rQw9tIHhCTgkmyY4mYSIFiuc36wHj50zDDI4gIBoiko1fPz o89w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703716114; x=1704320914; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TOTPntAbgy3PGTrBl7b5lPQZPt4hEISp0YHsUMdQkVM=; b=DlBrcpxq2zeY3NK70OIAPwtE27N8sYwV6A8p4S6y7QPchoAjyLzX+YcwsfsR0tnABu SHJxUAH/jJOW8yE0eKd1MHSqNDBdiwZqOEvNsj8kwqpD0ZxiSOoTNzGNLEHph1iL7vXA kpG7PTdS/xkUpl2xfi0XcD665nU47tvz+b68ro08I87Rb8IlA2CtGgodJJkVREFMsvx1 gj5OaEAY+QZRaWbTCuGkdV8fA+Bvk2+LlmGznIOAmswf3muR3O/lvQppsVFenD/UyqQL GO42u4QyHlNwg1dSlWfHhAQgfdiHljgJfs5Iy6RqtgVSrM7ipu9p8ZoXFHeFithU1Zzw rx1w== X-Gm-Message-State: AOJu0YwWXEmEi+QJmD3GdyUKurFfhDCL6jNca21rWICl//3vitZ4bJV2 yJ+EtebXjh3w2aWSph6dggL3qjB+WMWL3A== X-Received: by 2002:ac2:548b:0:b0:50e:36bc:747a with SMTP id t11-20020ac2548b000000b0050e36bc747amr3788065lfk.128.1703716113720; Wed, 27 Dec 2023 14:28:33 -0800 (PST) Received: from [10.167.154.1] (178235179028.dynamic-4-waw-k-1-3-0.vectranet.pl. [178.235.179.28]) by smtp.gmail.com with ESMTPSA id fb20-20020a1709073a1400b00a26a061ae1esm6854252ejc.97.2023.12.27.14.28.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Dec 2023 14:28:33 -0800 (PST) From: Konrad Dybcio <konrad.dybcio@linaro.org> Date: Wed, 27 Dec 2023 23:28:27 +0100 Subject: [PATCH 2/3] arm64: dts: qcom: sc8280xp: Correct USB PHY power domains Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231227-topic-8280_pcie_dts-v1-2-13d12b1698ff@linaro.org> References: <20231227-topic-8280_pcie_dts-v1-0-13d12b1698ff@linaro.org> In-Reply-To: <20231227-topic-8280_pcie_dts-v1-0-13d12b1698ff@linaro.org> To: Bjorn Andersson <andersson@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Johan Hovold <johan+linaro@kernel.org> Cc: Marijn Suijten <marijn.suijten@somainline.org>, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Konrad Dybcio <konrad.dybcio@somainline.org>, Konrad Dybcio <konrad.dybcio@linaro.org> X-Mailer: b4 0.12.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1703716109; l=1965; i=konrad.dybcio@linaro.org; s=20230215; h=from:subject:message-id; bh=VmfNU1/o30xTIL8Pi0ZpiDYz44NQF133gdGRmB0j+A0=; b=hkt2IT7RGZcKOjV7EFH8npQu9Q5Lojs0lNc697VJjqDjCIZ3m9BCDB/PTok2jUH2kpcYbGaLK HDW9gz58IuoBeaUtaWlu6ytDk67tB1yKYyVUV8yfVqnYEpj03699D7n X-Developer-Key: i=konrad.dybcio@linaro.org; a=ed25519; pk=iclgkYvtl2w05SSXO5EjjSYlhFKsJ+5OSZBjOkQuEms= X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1786475892707158428 X-GMAIL-MSGID: 1786475892707158428 |
Series |
SC8280XP preparatory PCIe fixes
|
|
Commit Message
Konrad Dybcio
Dec. 27, 2023, 10:28 p.m. UTC
The USB GDSCs are only related to the controllers. The PHYs on the other
hand, are powered by VDD_MX and their specific VDDA_PHY/PLL regulators.
Fix the power-domains assignment to stop potentially toggling the GDSC
unnecessarily.
Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Comments
On Wed, Dec 27, 2023 at 11:28:27PM +0100, Konrad Dybcio wrote: > The USB GDSCs are only related to the controllers. Are you sure? > The PHYs on the other > hand, are powered by VDD_MX and their specific VDDA_PHY/PLL regulators. > > Fix the power-domains assignment to stop potentially toggling the GDSC > unnecessarily. Again, there's no additional toggling being done here, but yes, this may keep the domains enabled during suspend depending on how the driver is implemented. If that's the concern, then please spell that out too. > Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") May not be needed either. > @@ -2597,7 +2597,7 @@ usb_2_qmpphy0: phy@88ef000 { > <&gcc GCC_USB3UNIPHY_PHY_MP0_BCR>; > reset-names = "phy", "phy_phy"; > > - power-domains = <&gcc USB30_MP_GDSC>; > + power-domains = <&rpmhpd SC8280XP_MX>; Johan
On 29.12.2023 14:01, Johan Hovold wrote: > On Wed, Dec 27, 2023 at 11:28:27PM +0100, Konrad Dybcio wrote: >> The USB GDSCs are only related to the controllers. > > Are you sure? That's what I've been told from rather reliable sources. > >> The PHYs on the other >> hand, are powered by VDD_MX and their specific VDDA_PHY/PLL regulators. >> >> Fix the power-domains assignment to stop potentially toggling the GDSC >> unnecessarily. > > Again, there's no additional toggling being done here, but yes, this may > keep the domains enabled during suspend depending on how the driver is > implemented. No, it can actually happen. (Some) QMP PHYs are referenced by the DP hardware. If USB is disabled (or suspended), the DP being active will hold these GDSCs enabled. Konrad > If that's the concern, then please spell that out too. > >> Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") > > May not be needed either. > >> @@ -2597,7 +2597,7 @@ usb_2_qmpphy0: phy@88ef000 { >> <&gcc GCC_USB3UNIPHY_PHY_MP0_BCR>; >> reset-names = "phy", "phy_phy"; >> >> - power-domains = <&gcc USB30_MP_GDSC>; >> + power-domains = <&rpmhpd SC8280XP_MX>; > > Johan
[ Please remember to trim your replies and add a newline before your inline comments to make them readable. ] On Fri, Dec 29, 2023 at 02:06:26PM +0100, Konrad Dybcio wrote: > On 29.12.2023 14:01, Johan Hovold wrote: > > On Wed, Dec 27, 2023 at 11:28:27PM +0100, Konrad Dybcio wrote: > >> Fix the power-domains assignment to stop potentially toggling the GDSC > >> unnecessarily. > > > > Again, there's no additional toggling being done here, but yes, this may > > keep the domains enabled during suspend depending on how the driver is > > implemented. > No, it can actually happen. (Some) QMP PHYs are referenced by the > DP hardware. If USB is disabled (or suspended), the DP being active > will hold these GDSCs enabled. That's not a "toggling", is it? Also if the DP controller is a consumer of these PHY's why should it not prevent the PHYs from suspending? Johan
On 29.12.2023 14:25, Johan Hovold wrote: > [ Please remember to trim your replies and add a newline before your > inline comments to make them readable. ] > > On Fri, Dec 29, 2023 at 02:06:26PM +0100, Konrad Dybcio wrote: >> On 29.12.2023 14:01, Johan Hovold wrote: >>> On Wed, Dec 27, 2023 at 11:28:27PM +0100, Konrad Dybcio wrote: > >>>> Fix the power-domains assignment to stop potentially toggling the GDSC >>>> unnecessarily. >>> >>> Again, there's no additional toggling being done here, but yes, this may >>> keep the domains enabled during suspend depending on how the driver is >>> implemented. > >> No, it can actually happen. (Some) QMP PHYs are referenced by the >> DP hardware. If USB is disabled (or suspended), the DP being active >> will hold these GDSCs enabled. > > That's not a "toggling", is it? Also if the DP controller is a consumer of > these PHY's why should it not prevent the PHYs from suspending? As far as I'm concerned, "toggling" is the correct word for "switching it on".. While the PHYs are indeed useful for getting displayport to work, the USB controller itself may not be necessary there, so enabling its power line would be a bit of a waste.. Konrad
On Fri, Dec 29, 2023 at 04:05:18PM +0100, Konrad Dybcio wrote: > On 29.12.2023 14:25, Johan Hovold wrote: > > On Fri, Dec 29, 2023 at 02:06:26PM +0100, Konrad Dybcio wrote: > >> On 29.12.2023 14:01, Johan Hovold wrote: > >>> On Wed, Dec 27, 2023 at 11:28:27PM +0100, Konrad Dybcio wrote: > > > >>>> Fix the power-domains assignment to stop potentially toggling the GDSC > >>>> unnecessarily. > >>> > >>> Again, there's no additional toggling being done here, but yes, this may > >>> keep the domains enabled during suspend depending on how the driver is > >>> implemented. > > > >> No, it can actually happen. (Some) QMP PHYs are referenced by the > >> DP hardware. If USB is disabled (or suspended), the DP being active > >> will hold these GDSCs enabled. > > > > That's not a "toggling", is it? Also if the DP controller is a consumer of > > these PHY's why should it not prevent the PHYs from suspending? > > As far as I'm concerned, "toggling" is the correct word for "switching it > on".. Hmm, this doesn't make sense. The PHY power domain will be disabled when the PHY is suspended, regardless of the DP controller. But sure, a system with USB disabled, would end up with the USB GDSC on. > While the PHYs are indeed useful for getting displayport to work, > the USB controller itself may not be necessary there, so enabling its > power line would be a bit of a waste.. Sure, if the PHYs truly don't need the USB PD then fine, this just doesn't seem to be case for PCIe, or at least the picture isn't as clear as your previous commit message suggested. Johan
On Fri, Dec 29, 2023 at 02:01:06PM +0100, Johan Hovold wrote: > On Wed, Dec 27, 2023 at 11:28:27PM +0100, Konrad Dybcio wrote: > > The USB GDSCs are only related to the controllers. > > Are you sure? > Yes, that's what I was told by UFS and PCIe teams and some of the internal documentation also confirms the same. > > The PHYs on the other > > hand, are powered by VDD_MX and their specific VDDA_PHY/PLL regulators. > > > > Fix the power-domains assignment to stop potentially toggling the GDSC > > unnecessarily. > > Again, there's no additional toggling being done here, but yes, this may > keep the domains enabled during suspend depending on how the driver is > implemented. > > If that's the concern, then please spell that out too. > > > Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") > > May not be needed either. > Fixes tag is indeed needed on this platform and all other platforms too. - Mani > > @@ -2597,7 +2597,7 @@ usb_2_qmpphy0: phy@88ef000 { > > <&gcc GCC_USB3UNIPHY_PHY_MP0_BCR>; > > reset-names = "phy", "phy_phy"; > > > > - power-domains = <&gcc USB30_MP_GDSC>; > > + power-domains = <&rpmhpd SC8280XP_MX>; > > Johan >
On Fri, Dec 29, 2023 at 10:40:08PM +0530, Manivannan Sadhasivam wrote: > On Fri, Dec 29, 2023 at 02:01:06PM +0100, Johan Hovold wrote: > > On Wed, Dec 27, 2023 at 11:28:27PM +0100, Konrad Dybcio wrote: > > > The USB GDSCs are only related to the controllers. > > > > Are you sure? > > Yes, that's what I was told by UFS and PCIe teams and some of the internal > documentation also confirms the same. Ok, good. I'm not sure I did a corresponding test of powering on a USB PHY without the corresponding USB GDSC enabled, so perhaps the issue I noted only applies to PCIe. Johan
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi index 72c5818b67f2..4b18a0762ca7 100644 --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi @@ -2597,7 +2597,7 @@ usb_2_qmpphy0: phy@88ef000 { <&gcc GCC_USB3UNIPHY_PHY_MP0_BCR>; reset-names = "phy", "phy_phy"; - power-domains = <&gcc USB30_MP_GDSC>; + power-domains = <&rpmhpd SC8280XP_MX>; #clock-cells = <0>; clock-output-names = "usb2_phy0_pipe_clk"; @@ -2621,7 +2621,7 @@ usb_2_qmpphy1: phy@88f1000 { <&gcc GCC_USB3UNIPHY_PHY_MP1_BCR>; reset-names = "phy", "phy_phy"; - power-domains = <&gcc USB30_MP_GDSC>; + power-domains = <&rpmhpd SC8280XP_MX>; #clock-cells = <0>; clock-output-names = "usb2_phy1_pipe_clk"; @@ -3109,7 +3109,7 @@ usb_0_qmpphy: phy@88eb000 { <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>; clock-names = "aux", "ref", "com_aux", "usb3_pipe"; - power-domains = <&gcc USB30_PRIM_GDSC>; + power-domains = <&rpmhpd SC8280XP_MX>; resets = <&gcc GCC_USB3_PHY_PRIM_BCR>, <&gcc GCC_USB4_DP_PHY_PRIM_BCR>; @@ -3162,7 +3162,7 @@ usb_1_qmpphy: phy@8903000 { <&gcc GCC_USB3_SEC_PHY_PIPE_CLK>; clock-names = "aux", "ref", "com_aux", "usb3_pipe"; - power-domains = <&gcc USB30_SEC_GDSC>; + power-domains = <&rpmhpd SC8280XP_MX>; resets = <&gcc GCC_USB3_PHY_SEC_BCR>, <&gcc GCC_USB4_1_DP_PHY_PRIM_BCR>;