[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZXrVxmxY6wZprbBa@hovoldconsulting.com>
Date: Thu, 14 Dec 2023 11:15:34 +0100
From: Johan Hovold <johan@...nel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: andersson@...nel.org, konrad.dybcio@...aro.org, vkoul@...nel.org,
sboyd@...nel.org, mturquette@...libre.com, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH 00/16] Fix Qcom UFS PHY clocks
On Thu, Dec 14, 2023 at 02:40:45PM +0530, Manivannan Sadhasivam wrote:
> This series fixes the clocks supplied to QMP PHY IPs in the Qcom SoCs. All
> of the Qcom SoCs except MSM8996 require 3 clocks for QMP UFS:
>
> * ref - 19.2MHz reference clock from RPM/RPMh
> * ref_aux - Auxiliary reference clock from GCC
> * qref - QREF clock from GCC or TCSR (TCSR since SM8550)
>
> MSM8996 only requires 'ref' and 'qref' clocks.
>
> Hence, this series fixes the binding, DT and GCC driver to reflect the
> actual clock topology.
Is this based on documentation for all the SoCs or on inference from the
current (upstream and downstream) devicetrees?
Are you sure that you should not just describe that some of these UFS
reference clocks are sourced from CXO in the clock driver instead?
Take a look at commits
f446022b932a ("arm64: dts: qcom: sc8280xp: fix UFS reference clocks")
f6abcc21d943 ("clk: qcom: gcc-sc8280xp: add cxo as parent for three ufs ref clks")
Johan
Powered by blists - more mailing lists