[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <170344745824.2405994.11750508038108170854.b4-ty@sntech.de>
Date: Sun, 24 Dec 2023 20:54:45 +0100
From: Heiko Stuebner <heiko@...ech.de>
To: Sam Edwards <cfsworks@...il.com>,
Rob Herring <robh+dt@...nel.org>
Cc: Heiko Stuebner <heiko@...ech.de>,
Sam Edwards <CFSworks@...il.com>,
linux-rockchip@...ts.infradead.org,
Joshua Riek <jjriek@...izon.net>,
linux-arm-kernel@...ts.infradead.org,
Daniel Kukieła <daniel@...iela.pl>,
linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org,
Sven Rademakers <sven.rademakers@...il.com>
Subject: Re: [PATCH] arm64: dts: rockchip: rk3588: Fix USB PD clocks
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,
--
Heiko Stuebner <heiko@...ech.de>
Powered by blists - more mailing lists