Message ID | 20231216021019.1543811-1-CFSworks@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-1952-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp9706073dys; Fri, 15 Dec 2023 18:11:05 -0800 (PST) X-Google-Smtp-Source: AGHT+IEqNxiDTeoLPfVzLc2jqavxE8xSYEnPd+xIdB4bXrLa2aIjzAyFFpbvrD2roLtUW/ZVTn/8 X-Received: by 2002:a50:c35c:0:b0:552:f8e3:b47f with SMTP id q28-20020a50c35c000000b00552f8e3b47fmr181168edb.83.1702692665090; Fri, 15 Dec 2023 18:11:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702692665; cv=none; d=google.com; s=arc-20160816; b=blUu+Fygh/FbgIXA4CCLcjeWMko6wnOoCvsqn7pCRyt5L3GEWQK+IYlfnReqkOdg71 d8QxipE/1jHt2eXHJW5OXHWCAG82nQTodiqwWSovZTj0gVHkhaTLx6eLwg3d+LHbmmZD gnhSe7/fWNDRz28Ak5sVoXiiY5pyMU1Bc2sjVykbZ+juiY/1y36qT0xO27fMAA13se8/ /6zrRs7RQ0qC9Xs2x+Q47ZVqTIHaR6QDUeoPNgnXVUiqv+eJQrPLsWG87vnljFcnj/k8 TQJedvbUfJTh7PVYN11I/5m6tN24H6Kkv6Ohf6O9HUlaY8zGQDbdJYOdZkpBNd3pqEYz tJgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=McVfGfyP695CBBV4Dy191zoW62rsgzuHJs0dXDvRxJc=; fh=WsPG8bmoeVdJ+mTvc3JfGT690EmTY9Rsmm35P0eF47I=; b=BWjyGSJSWfk6uMeld/SD7kWgRhYahuaEGZ05vnJRohRGhshcYCFCLQVVn2QtEhdXud WY+HtAIVpnkDlfiq6B+q7zUp0uMSyt2ZqwVcobNK276oR9+IHgMdmQnxZdVKU1+Ca867 aIz9WBd6SPty4dC7HnMMGaJ4HkHdP17awnOnivq+3K6U3ukv0uprgFSTNGiEdafKO+X7 N6tnhbhR9Y1za6p5IJJ9DepeTYn6YMoZCFj004sZOmKEJXHobJm4+6bKsqOuvchKvj57 w9jHs7xZla6/CSNSniRzkOxJYN/cqC8Tmyx6ZriqflBZSe9d5KI69WF6zk+qfU1OAN9J tqPQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=M88rzfJM; spf=pass (google.com: domain of linux-kernel+bounces-1952-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1952-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id a5-20020a509b45000000b0054cc22a2c7csi7748801edj.203.2023.12.15.18.11.04 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 18:11:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-1952-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=M88rzfJM; spf=pass (google.com: domain of linux-kernel+bounces-1952-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1952-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com 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 am.mirrors.kernel.org (Postfix) with ESMTPS id AFB021F23A99 for <ouuuleilei@gmail.com>; Sat, 16 Dec 2023 02:11:04 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D2B155685; Sat, 16 Dec 2023 02:10:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="M88rzfJM" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-oa1-f48.google.com (mail-oa1-f48.google.com [209.85.160.48]) (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 A92F415C6; Sat, 16 Dec 2023 02:10:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-1f5bd86ceb3so859684fac.2; Fri, 15 Dec 2023 18:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702692624; x=1703297424; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=McVfGfyP695CBBV4Dy191zoW62rsgzuHJs0dXDvRxJc=; b=M88rzfJMR6aYzW7ZmTG3U4QxTV+el22RnA9m4lzJs1VUj2FhITHAhfsoiLlGRNxOsn 6oB2879dXfAbBSyvBEWlyg2cHDPzXKvbh5lG1IUFi6jV8PDTD+zoxF8jYUlPAQC4D586 At0PtSD6ElUZ2eD9hgpvEokCuz7I44ZWI2njdxixYiy0nmV9WTNnSeVgg3GvZBrTrMve GUOIgWhpmyxR2J4yspd30FmNqFPwzfSrlOHo1pgq3pHX1WoPWxhy4id39eTydeB/u26f oSRHuKVFMWsjFxR/YaewcLxIlgmXY1aCB0xTlAT45CG52TN5Pd/XPB9B9oLY+HRlriB3 iYHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702692624; x=1703297424; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=McVfGfyP695CBBV4Dy191zoW62rsgzuHJs0dXDvRxJc=; b=Zpf1q2PoPBnqUo3gtIixJyfuSBWJuEHoaok7OeVbltwKWT58RZ/MwJvbY3U+2+HNgG YvB4aEQWmHCBePHKkhP+98h/GxfUppxsmD4f2mePFI6irDUJnHegQeaFMqXxo5PHEq6X P8sh9Q9e4ebNrXDAc6Jw20pc1ATLNOiAiG0xZKfIS6CDWavTaA5iB7p9vc9kfcpDNdMb +dj9tcui/jd42J0A++G3A8vPq8lcu/SX+qWQLywUfEBZsPjBwX3P8a87VkWoyW2E+d7o d6ZKM9rwYJaeQ0yKiggwHkhUNKjsbR4YWrMFp014m7hufnftqF066qBVfh1RTeDYyJ/B /jNg== X-Gm-Message-State: AOJu0YySSG17bAlOiGi+HTzhIOi8BRGXn7k/VUGfoghDKTrU/+1iPfTu FOM2G8k5KtXIjkMudHcQ3K4CjwF2avIGJ0R/ X-Received: by 2002:a05:6870:a68a:b0:203:294a:50da with SMTP id i10-20020a056870a68a00b00203294a50damr6322456oam.75.1702692624475; Fri, 15 Dec 2023 18:10:24 -0800 (PST) Received: from celestia.nettie.lan ([2001:470:42c4:101:7c7f:3273:a81a:4618]) by smtp.gmail.com with ESMTPSA id hq15-20020a0568709b0f00b002032d9a4c0dsm1621924oab.43.2023.12.15.18.10.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 18:10:24 -0800 (PST) From: Sam Edwards <cfsworks@gmail.com> X-Google-Original-From: Sam Edwards <CFSworks@gmail.com> To: Heiko Stuebner <heiko@sntech.de>, Rob Herring <robh+dt@kernel.org> Cc: linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, =?utf-8?q?Daniel_?= =?utf-8?q?Kukie=C5=82a?= <daniel@kukiela.pl>, Sven Rademakers <sven.rademakers@gmail.com>, Joshua Riek <jjriek@verizon.net>, Sam Edwards <CFSworks@gmail.com> Subject: [PATCH] arm64: dts: rockchip: rk3588: Fix USB PD clocks Date: Fri, 15 Dec 2023 19:10:19 -0700 Message-ID: <20231216021019.1543811-1-CFSworks@gmail.com> X-Mailer: git-send-email 2.41.0 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-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785402664117760965 X-GMAIL-MSGID: 1785402664117760965 |
Series |
arm64: dts: rockchip: rk3588: Fix USB PD clocks
|
|
Commit Message
Sam Edwards
Dec. 16, 2023, 2:10 a.m. UTC
The QoS blocks saved/restored when toggling the PD_USB power domain are
clocked by ACLK_USB. Attempting to access these memory regions without
that clock running will result in an indefinite CPU stall.
The PD_USB node wasn't specifying this clock dependency, resulting in
hangs when trying to toggle the power domain (either on or off), unless
we get "lucky" and have ACLK_USB running for another reason at the time.
This "luck" can result from the bootloader leaving USB powered/clocked,
and if no built-in driver wants USB, Linux will disable the unused
PD+CLK on boot when {pd,clk}_ignore_unused aren't given. This can also
be unlucky because the two cleanup tasks run in parallel and race: if
the CLK is disabled first, the PD deactivation stalls the boot. In any
case, the PD cannot then be reenabled (if e.g. the driver loads later)
once the clock has been stopped.
Fix this by specifying a dependency on ACLK_USB, instead of only
ACLK_USB_ROOT. The child-parent relationship means the former implies
the latter anyway. By the same token, remove the redundant HCLK_USB_ROOT
reference, since that's also implied by its HCLK_HOST* grandchildren.
Fixes: c9211fa2602b8 ("arm64: dts: rockchip: Add base DT for rk3588 SoC")
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
---
Hi list,
Feel free to tell me to knock the HCLK_USB_ROOT change out of there, since it's
not strictly necessary for this fix. It was a "while I'm at it, let's remove
this redundant reference" thing. :)
I also do not know quite enough about debugfs to know how to manually request
clocks and PDs, but if such a mechanism exists, it would be a good way to
confirm the correctness of this fix: ensure ACLK_USB is stopped, then try to
toggle PD_USB a few times.
Cheers,
Sam
---
arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Comments
On Fri, 15 Dec 2023 19:10:19 -0700, Sam Edwards wrote: > The QoS blocks saved/restored when toggling the PD_USB power domain are > clocked by ACLK_USB. Attempting to access these memory regions without > that clock running will result in an indefinite CPU stall. > > The PD_USB node wasn't specifying this clock dependency, resulting in > hangs when trying to toggle the power domain (either on or off), unless > we get "lucky" and have ACLK_USB running for another reason at the time. > This "luck" can result from the bootloader leaving USB powered/clocked, > and if no built-in driver wants USB, Linux will disable the unused > PD+CLK on boot when {pd,clk}_ignore_unused aren't given. This can also > be unlucky because the two cleanup tasks run in parallel and race: if > the CLK is disabled first, the PD deactivation stalls the boot. In any > case, the PD cannot then be reenabled (if e.g. the driver loads later) > once the clock has been stopped. > > [...] Applied, thanks! [1/1] arm64: dts: rockchip: rk3588: Fix USB PD clocks commit: 44de8996ed5a10f08f2fe947182da6535edcfae5 I've changed the patch to only add the ACLK_USB. For the HCLK_* type, Rockchip added both the root as well as the actual controller clocks, so I guess it should be the same for the ACLK-type. Powerdomains are strange with their clock- synchronization, so I'm opting for better save than sorry ;-) Best regards,
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi index fd1b5d02ba16..32d7e49f03d3 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi @@ -1341,8 +1341,7 @@ power-domain@RK3588_PD_RGA31 { power-domain@RK3588_PD_USB { reg = <RK3588_PD_USB>; clocks = <&cru PCLK_PHP_ROOT>, - <&cru ACLK_USB_ROOT>, - <&cru HCLK_USB_ROOT>, + <&cru ACLK_USB>, <&cru HCLK_HOST0>, <&cru HCLK_HOST_ARB0>, <&cru HCLK_HOST1>,