[v3,0/4] Add Acer Aspire 1

This series introduces Acer Aspire 1 - A WoA laptop with sc7180.

The dts adds mostly complite support for the hardware and the device,
with minor patches on top, can be used as a normal laptop daily.

Notable features absent from this patch:
- Sound
   While the dedicated sound components are defined, since the
   ADSP must be used, sound requires additions of that remoteproc
   as well some extra "glue" to connect the i2s outputs to it.
   I was able to hack together some sound based on sm8250 stuff
   but it needs more work.
- Embedded Controller
   The laptop has a dedicated EC that controls, notably,
   battery/charger and notifies the device about the USB-C DisplayPort
   HPD events. As per this patch, there is no battery status
   indication and external display support. Also, due to the EC
   defaults, the fn key is disabled. I have an experimental driver that
   implements all of that, which needs more work and will be submitted
   at a later date.
- PSCI OSI Mode
   Firmware on this laptop does not support the PC mode, as is usual
   for Qualcomm. This change would require adding OSI related
   power-domains to the SoC dtsi and is omitted in expectation that
   this can be handled when (if?) CrOS team handles their tf-a, like
   they did with sc7280.

Changed in v3:
 - Disable lpass clocks by default (Konrad)
 - Drop status=disabled for mdp in the common soc dtsi (Konrad)

Nikita Travkin (4):
  arm64: dts: qcom: sc7180: Don't enable lpass clocks by default
  arm64: dts: qcom: sc7180: Drop redundant disable in mdp
  dt-bindings: arm: qcom: Add Acer Aspire 1
  arm64: dts: qcom: Add Acer Aspire 1

 .../devicetree/bindings/arm/qcom.yaml         |   4 +-
 arch/arm64/boot/dts/qcom/Makefile             |   1 +
 .../boot/dts/qcom/sc7180-acer-aspire1.dts     | 859 ++++++++++++++++++
 arch/arm64/boot/dts/qcom/sc7180-idp.dts       |   4 -
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi  |  12 +-
 arch/arm64/boot/dts/qcom/sc7180.dtsi          |   6 +-
 6 files changed, 874 insertions(+), 12 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/sc7180-acer-aspire1.dts

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 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!