Re: [PATCH v3 1/4] arm64: dts: qcom: sc7180: Don't enable lpass clocks by default

From: Matthias Kaehlcke
Date: Thu Mar 16 2023 - 13:28:32 EST


On Thu, Mar 16, 2023 at 08:42:03AM +0500, Nikita Travkin wrote:
> Matthias Kaehlcke писал(а) 16.03.2023 05:28:
> > On Wed, Mar 15, 2023 at 08:43:08PM +0500, Nikita Travkin wrote:
> >> lpass clocks are usually blocked from HLOS by the firmware and
> >> instead are managed by the ADSP. Mark them as reserved and explicitly
> >> enable in the CrOS boards that have special, cooperative firmware.
> >>
> >> Signed-off-by: Nikita Travkin <nikita@xxxxxxx>
> >> ---
> >> arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 8 ++++++++
> >> arch/arm64/boot/dts/qcom/sc7180.dtsi | 4 ++++
> >> 2 files changed, 12 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> >> index 423630c4d02c..26def6e12723 100644
> >> --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> >> +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> >> @@ -785,6 +785,14 @@ alc5682: codec@1a {
> >> };
> >> };
> >>
> >> +&lpasscc {
> >> + status = "okay";
> >> +};
> >> +
> >> +&lpass_hm {
> >> + status = "okay";
> >> +};
> >> +
> >> &lpass_cpu {
> >> status = "okay";
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> >> index 53f0076f20f6..f0de177981f9 100644
> >> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> >> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> >> @@ -3623,6 +3623,8 @@ lpasscc: clock-controller@62d00000 {
> >> power-domains = <&lpass_hm LPASS_CORE_HM_GDSCR>;
> >> #clock-cells = <1>;
> >> #power-domain-cells = <1>;
> >> +
> >> + status = "reserved"; /* Controlled by ADSP */
> >
> > Why not "disabled"? I see "reserved" is used in a couple of other
> > instances, but it doesn't appear in Documentation/devicetree/bindings/,
> > so it doesn't seem to have a well defined meaning that distinguishes it
> > from "disabled".
>
> Hi, the standard properties like this one are defined in the
> Devicetree specification, notably chapter 2.3.4 "status" says:
>
> "reserved" Indicates that the device is operational, but should
> not be used. Typically this is used for devices that are controlled
> by another software component, such as platform firmware.
>
> On the contrary,
>
> "disabled" Indicates that the device is not presently operational (...)
>
> Since the hardware is operational but is controlled by "foreign"
> firmware, I believe "reserved" state is more correct here.

Thanks for the clarification!