Message ID | 20230315154311.37299-2-nikita@trvn.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp2402032wrd; Wed, 15 Mar 2023 08:44:54 -0700 (PDT) X-Google-Smtp-Source: AK7set+D70fKDySUDhUZYCo83xWGvElduOaWFBhWrlQkH5jtRW+fPYtuaRZol1rTaks8HeFchm+5 X-Received: by 2002:a62:1781:0:b0:5a9:c43a:5810 with SMTP id 123-20020a621781000000b005a9c43a5810mr27804222pfx.25.1678895094506; Wed, 15 Mar 2023 08:44:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678895094; cv=none; d=google.com; s=arc-20160816; b=AgEBAWbCm/c9U/Tnkpv+TCamQqvg2xUDtgWekq3noLzoXyqWfmxEBsNo9zSzvv1Yna gpVkNshZ6oAwx0l5ThZlKJ9HaWuBM9n3vsMjG1ChKTTpeeE+0G0Lpx7pOpznpZoBwMmt irhfk4usIKMOIcSK5jC2fGjuRV/eFrmXJnUMPFgDiUa1IXG2dJtlCkiid29MWUXBMEgF CR2ge2EVfANo0KEU57NzuT6waXwoyAcNG4Zi1gqCaiTauh2yzmQ4WOq/QaMtl8epZWhT MKUaO5g9qbFvppWrWaIskEWR8gi2hpxkvrGL7LauFgbVKFkQ704LSLgrBgl+7Fxl6AWM pUUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Lq2XgL1LUeBHA2dYHGpkbwr5U+E4pZBI24662eq604I=; b=yPFQ16XuxBKdsTTnuQX2vpBLdbUQFv2RPY4VUg3wdp3MfZQVL11BuYf4YVZoSMtzjN RkaHTgvFclFMfmBSGgt9EcocwgPhFnaebJswJyyqiLJbnl916lIb3sdyZacygSUPWFDp 6JuZ0nCk2kJCxyvOfeVTFPLRe0S+OK6BL8E2cY0ul6SQLmgd81c66RGryS8aGar6hQPi R3baeOyYusWkuQxtPMZv01GNq/OVGcTDnqgRRdklFE9EYMHtNvmLVjKo88yETholm6Zz 17pPNYKiKS/E7dEs9SO5NitAVZOUgQQN/9giroo41hgR2E0qezYKmbf1Kiu3sjzW274l HtGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@trvn.ru header.s=mail header.b=yBn4xK9I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=trvn.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p14-20020aa79e8e000000b005935dae4234si5222908pfq.306.2023.03.15.08.44.38; Wed, 15 Mar 2023 08:44:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@trvn.ru header.s=mail header.b=yBn4xK9I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=trvn.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232593AbjCOPnx (ORCPT <rfc822;ruipengqi7@gmail.com> + 99 others); Wed, 15 Mar 2023 11:43:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232286AbjCOPnq (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 15 Mar 2023 11:43:46 -0400 Received: from box.trvn.ru (box.trvn.ru [194.87.146.52]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81D75664D3; Wed, 15 Mar 2023 08:43:22 -0700 (PDT) Received: from authenticated-user (box.trvn.ru [194.87.146.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by box.trvn.ru (Postfix) with ESMTPSA id 0BA7B40AC9; Wed, 15 Mar 2023 20:43:19 +0500 (+05) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=trvn.ru; s=mail; t=1678894999; bh=bHma5jkgRzcDX6jZxn7KcOr5IxK0IUPT6jvQbfkxZKs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yBn4xK9IC4H97jwGWZrl2EaeztgwsGf0MzvdXtcK77AvXSHCxZ+7edYzGL7gdkG68 LucwaFoZDh5qKq/KbT5LmwmaHbkWQP8n7WOTIEYgqrKygvMVE0Zjcv+F4tNB/wi/z3 jx0LfDRJanrD99fbpatmQS0uVMbQHChRZv4pybmxbYYv/2jCF2ND5VgsMpQmqGqdrQ QVUyDJgbwKYjFnfPW2t1447OaImnx9o0WOWitpGe49302ZKqW0lImHhUIMbhE5XZyd u/01DYJzU5tRO1+8IWDKN1RrfbpuscZ2mTCaAp3Pz3vZyQ6lacMupRQeUtZbpYeOnf X7XyixaAWGCnw== From: Nikita Travkin <nikita@trvn.ru> To: agross@kernel.org, andersson@kernel.org Cc: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, konrad.dybcio@linaro.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht, Nikita Travkin <nikita@trvn.ru> Subject: [PATCH v3 1/4] arm64: dts: qcom: sc7180: Don't enable lpass clocks by default Date: Wed, 15 Mar 2023 20:43:08 +0500 Message-Id: <20230315154311.37299-2-nikita@trvn.ru> In-Reply-To: <20230315154311.37299-1-nikita@trvn.ru> References: <20230315154311.37299-1-nikita@trvn.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760449102647240353?= X-GMAIL-MSGID: =?utf-8?q?1760449102647240353?= |
Series |
Add Acer Aspire 1
|
|
Commit Message
Nikita Travkin
March 15, 2023, 3:43 p.m. UTC
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@trvn.ru>
---
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 8 ++++++++
arch/arm64/boot/dts/qcom/sc7180.dtsi | 4 ++++
2 files changed, 12 insertions(+)
Comments
On 15.03.2023 16:43, 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@trvn.ru> > --- +CC Doug Please confirm whether this also applies to IDP (in which case this would have been a bugfix). Konrad > 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 */ > }; > > lpass_cpu: lpass@62d87000 { > @@ -3671,6 +3673,8 @@ lpass_hm: clock-controller@63000000 { > > #clock-cells = <1>; > #power-domain-cells = <1>; > + > + status = "reserved"; /* Controlled by ADSP */ > }; > }; >
Hi, On Wed, Mar 15, 2023 at 9:12 AM Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > On 15.03.2023 16:43, 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@trvn.ru> > > --- > +CC Doug > > Please confirm whether this also applies to IDP (in which case > this would have been a bugfix). Thanks for the CC! Actually, Judy (and maybe Matthias) might be better. The audio stuff makes my head spin a little bit and I know they've kept track of it much better than I have. If they don't have time, I can dig more into it myself. I also added Srinivasa just in case. In general, though, I think people at Google don't interact with IDP very much. It's a reference board from Qualcomm and not the right form factor. It also doesn't support most of the tooling that folks at Google on the ChromeOS team expect. I don't know if audio was ever really supported on IDP. Probably not since there's no "sound" node in the IDP device tree file. > Konrad > > 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 */ > > }; > > > > lpass_cpu: lpass@62d87000 { > > @@ -3671,6 +3673,8 @@ lpass_hm: clock-controller@63000000 { > > > > #clock-cells = <1>; > > #power-domain-cells = <1>; > > + > > + status = "reserved"; /* Controlled by ADSP */ > > }; > > }; > >
On Wed, Mar 15, 2023 at 05:06:04PM -0700, Doug Anderson wrote: > Hi, > > On Wed, Mar 15, 2023 at 9:12 AM Konrad Dybcio <konrad.dybcio@linaro.org> wrote: > > > > > > > > On 15.03.2023 16:43, 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@trvn.ru> > > > --- > > +CC Doug > > > > Please confirm whether this also applies to IDP (in which case > > this would have been a bugfix). > > Thanks for the CC! Actually, Judy (and maybe Matthias) might be > better. The audio stuff makes my head spin a little bit and I know > they've kept track of it much better than I have. If they don't have > time, I can dig more into it myself. I also added Srinivasa just in > case. > > In general, though, I think people at Google don't interact with IDP > very much. It's a reference board from Qualcomm and not the right form > factor. It also doesn't support most of the tooling that folks at > Google on the ChromeOS team expect. I don't know if audio was ever > really supported on IDP. Probably not since there's no "sound" node in > the IDP device tree file. I don't know about the history of audio on the IDP either, I share Doug's assessment that it looks like it was never supported. > > Konrad > > > 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 */ > > > }; > > > > > > lpass_cpu: lpass@62d87000 { > > > @@ -3671,6 +3673,8 @@ lpass_hm: clock-controller@63000000 { > > > > > > #clock-cells = <1>; > > > #power-domain-cells = <1>; > > > + > > > + status = "reserved"; /* Controlled by ADSP */ > > > }; > > > }; > > >
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@trvn.ru> > --- > 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". > }; > > lpass_cpu: lpass@62d87000 { > @@ -3671,6 +3673,8 @@ lpass_hm: clock-controller@63000000 { > > #clock-cells = <1>; > #power-domain-cells = <1>; > + > + status = "reserved"; /* Controlled by ADSP */ > }; > }; > > -- > 2.39.2 >
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@trvn.ru> >> --- >> 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 looking at the patch! Nikita > >> }; >> >> lpass_cpu: lpass@62d87000 { >> @@ -3671,6 +3673,8 @@ lpass_hm: clock-controller@63000000 { >> >> #clock-cells = <1>; >> #power-domain-cells = <1>; >> + >> + status = "reserved"; /* Controlled by ADSP */ >> }; >> }; >> >> -- >> 2.39.2 >>
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@trvn.ru> > >> --- > >> 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!
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 */ }; lpass_cpu: lpass@62d87000 { @@ -3671,6 +3673,8 @@ lpass_hm: clock-controller@63000000 { #clock-cells = <1>; #power-domain-cells = <1>; + + status = "reserved"; /* Controlled by ADSP */ }; };