Message-ID: <6db0c9da3a05ee8adaf7262ebce16d3d.sboyd@kernel.org>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <df133e5a-8030-0774-091c-6f8e0692e945@linaro.org>
References: <20230118132254.2356209-1-dmitry.baryshkov@linaro.org> <20230118132254.2356209-8-dmitry.baryshkov@linaro.org> <7055af43f4a8894ac34e53c5847fb3de.sboyd@kernel.org> <63f017c7-d320-a996-7bda-33d263a847bc@linaro.org> <525ef5cdefe987c3412249760324eb09.sboyd@kernel.org> <df133e5a-8030-0774-091c-6f8e0692e945@linaro.org>
Subject: Re: [PATCH v4 7/7] clk: qcom: add the driver for the MSM8996 APCS clocks
From:   Stephen Boyd <sboyd@kernel.org>
Cc:     linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
To:     Andy Gross <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
        Jassi Brar <jassisinghbrar@gmail.com>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Michael Turquette <mturquette@baylibre.com>,
        Rob Herring <robh+dt@kernel.org>,
        Taniya Das <quic_tdas@quicinc.com>
Date:   Wed, 25 Jan 2023 15:15:40 -0800
User-Agent: alot/0.10
Precedence: bulk

Quoting Konrad Dybcio (2023-01-25 14:05:27)
>=20
> On 25.01.2023 22:56, Stephen Boyd wrote:
> >=20
> > So it is waiting for the CPU clk to be stable? The comment is not clear.
> Okay, so perhaps this is just a misunderstanding because of a lackluster
> comment.. This SYS_APCS_AUX (provided by this driver) is one of the CPU
> clock sources (and probably the "safest" of them all, as it's fed by
> GPLL0 and not the CPU PLLs) the delay is there to ensure it can
> stabilize after setting the divider to DIV2. In a theoretical case, the
> big 8996 cpucc driver could select this clock as a target for one (or
> both) of the per-cluster muxes and it could put the CPUs in a weird state.
>=20
> As unlikely as that would be, especially considering 8996 (AFAIK) doesn't
> use this clock source coming out of reset / bootloader, this lets us
> ensure one less thing can break.

Great! I look forward to a better comment.