Received-SPF: pass (google.com: domain of linux-kernel+bounces-179837-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240226065113.1690534-1-nick.hu@sifive.com> <CAPDyKFph3WsZMmALnzBQKE4S_80Ji5h386Wi0vHda37QUsjMtg@mail.gmail.com>
 <CAKddAkDcdaXKzpcKN=LCCx9S4Trv+joLX2s=nyhzaRtM5HorqA@mail.gmail.com>
 <CAKddAkC6N=Cfo0z+F8herKTuJzCyt_MA0vWNbLCr6CbQnj0y8g@mail.gmail.com>
 <CAPDyKFr_M0NDH0gaunBpybnALOFfz4LpX4_JW2GCUxjwGzdZsg@mail.gmail.com>
 <CAKddAkC5CRX+ZTh=MgzPYU72SY13+AQYhknhV_CC+=XX9=DKyg@mail.gmail.com>
 <CAAhSdy1SDd=VUqDQA0T5n9LwHo=3uGzFq1dUcbDFcB3aBdaioA@mail.gmail.com> <CAAhSdy33DcNw+pbDRrR=hBH86kwvu3xZbomQby8XhRXcc-exqQ@mail.gmail.com>
In-Reply-To: <CAAhSdy33DcNw+pbDRrR=hBH86kwvu3xZbomQby8XhRXcc-exqQ@mail.gmail.com>
From: Nick Hu <nick.hu@sifive.com>
Date: Wed, 15 May 2024 20:15:24 +0800
Message-ID: <CAKddAkBrP2iQBC+aY1Xw5pssBpiQZe4V-6ww5m8hbKP6V0jzLg@mail.gmail.com>
Subject: Re: [PATCH] cpuidle: riscv-sbi: Add cluster_pm_enter()/exit()
To: Anup Patel <anup@brainfault.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>, palmer@dabbelt.com, rafael@kernel.org, 
	daniel.lezcano@linaro.org, paul.walmsley@sifive.com, linux-pm@vger.kernel.org, 
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, 
	zong.li@sifive.com, Cyan Yang <cyan.yang@sifive.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Anup,

Thank you for your guidance.
After enabling the debug message, we found a way to solve the problem
by the following steps:
1. Add a compatible string in 'power-domains' node otherwise it won't
be the supplier of the consumers. (See of_link_to_phandle())
2. Move the 'power-domains' node outside the 'cpus' node otherwise it
won't be added to the device hierarchy by device_add().
3. Update the cpuidle-riscv-sbi driver to get the pds_node from
'/power-domains'.

So the DTS will be like:
cpus {
    ...
     domain-idle-states {
           CLUSTER_SLEEP:cluster-sleep {
                        compatible =3D "domain-idle-state";
                        ...
            }
     }
}
power-domains {
            compatible =3D "riscv,sbi-power-domains"
            ...
            ...
            CLUSTER_PD: clusterpd {
                    domain-idle-states =3D <&CLUSTER_SLEEP>;
            };
}
soc {
      deviceA@xxx{
             ...
             power-domains =3D <&CLUSTER_PD>;
             ...
      }
}

Regards,
Nick

On Tue, May 14, 2024 at 10:54=E2=80=AFPM Anup Patel <anup@brainfault.org> w=
rote:
>
> On Tue, May 14, 2024 at 7:53=E2=80=AFPM Anup Patel <anup@brainfault.org> =
wrote:
> >
> > Hi Nick,
> >
> > On Tue, May 14, 2024 at 3:20=E2=80=AFPM Nick Hu <nick.hu@sifive.com> wr=
ote:
> > >
> > > Hi Ulf,
> > >
> > > Thank you for your valuable suggestion.
> > > I sincerely apologize for the delay in responding to your message. We
> > > have diligently worked on experimenting with the suggestion you
> > > provided.
> > >
> > > As per your recommendation, we have incorporated the "power-domains=
=3D<>
> > > property" into the consumer's node, resulting in modifications to the
> > > DTS as illustrated below:
> > >
> > > cpus {
> > >     ...
> > >      domain-idle-states {
> > >            CLUSTER_SLEEP:cluster-sleep {
> > >                         compatible =3D "domain-idle-state";
> > >                         ...
> > >             }
> > >      }
> > >      power-domains {
> > >             ...
> > >             ...
> > >             CLUSTER_PD: clusterpd {
> > >                     domain-idle-states =3D <&CLUSTER_SLEEP>;
> > >             };
> > >      }
> > > }
> > > soc {
> > >       deviceA@xxx{
> > >              ...
> > >              power-domains =3D <&CLUSTER_PD>;
> > >              ...
> > >       }
> > > }
> > >
> > > However, this adjustment has led to an issue where the probe for
> > > 'deviceA' is deferred by 'device_links_check_suppliers()' within
> > > 'really_probe()'. In an attempt to mitigate this issue, we
> > > experimented with a workaround by adding the attribute
> > > "status=3D"disabled"" to the 'CLUSTER_PD' node. This action aimed to
> > > prevent the creation of a device link between 'deviceA' and
> > > 'CLUSTER_PD'. Nevertheless, we remain uncertain about the
> > > appropriateness of this solution.
> > >
> > > Do you have suggestions on how to effectively address this issue?
> >
> > I totally missed this email since I was not CC'ed sorry about that. Ple=
ase
> > use get_maintainers.pl when sending patches.
>
> I stand corrected. This patch had landed in the "spam" folder. I don't kn=
ow why.
>
> Regards,
> Anup
>
> >
> > The genpd_add_provider() (called by of_genpd_add_provider_simple())
> > does mark the power-domain DT node as initialized (fwnode_dev_initializ=
ed())
> > so after the cpuidle-riscv-sbi driver is probed the 'deviceA' dependenc=
y is
> > resolved and 'deviceA' should be probed unless there are other unmet
> > dependencies.
> >
> > Try adding "#define DEBUG" before all includes in drivers/core/base.c
> > and add "loglevel=3D8" in kernel parameters, this will print producer-c=
onsumer
> > linkage of all devices.
> >
> > Marking the power-domain DT node as "disabled" is certainly not the
> > right way.
> >
> > Regards,
> > Anup
> >
> > >
> > > Regards,
> > > Nick
> > >
> > > On Tue, Apr 30, 2024 at 4:13=E2=80=AFPM Ulf Hansson <ulf.hansson@lina=
ro.org> wrote:
> > > >
> > > > On Mon, 29 Apr 2024 at 18:26, Nick Hu <nick.hu@sifive.com> wrote:
> > > > >
> > > > > On Tue, Apr 30, 2024 at 12:22=E2=80=AFAM Nick Hu <nick.hu@sifive.=
com> wrote:
> > > > > >
> > > > > > Hi Ulf
> > > > > >
> > > > > > On Mon, Apr 29, 2024 at 10:32=E2=80=AFPM Ulf Hansson <ulf.hanss=
on@linaro.org> wrote:
> > > > > > >
> > > > > > > On Mon, 26 Feb 2024 at 07:51, Nick Hu <nick.hu@sifive.com> wr=
ote:
> > > > > > > >
> > > > > > > > When the cpus in the same cluster are all in the idle state=
, the kernel
> > > > > > > > might put the cluster into a deeper low power state. Call t=
he
> > > > > > > > cluster_pm_enter() before entering the low power state and =
call the
> > > > > > > > cluster_pm_exit() after the cluster woken up.
> > > > > > > >
> > > > > > > > Signed-off-by: Nick Hu <nick.hu@sifive.com>
> > > > > > >
> > > > > > > I was not cced this patch, but noticed that this patch got qu=
eued up
> > > > > > > recently. Sorry for not noticing earlier.
> > > > > > >
> > > > > > > If not too late, can you please drop/revert it? We should rea=
lly move
> > > > > > > away from the CPU cluster notifiers. See more information bel=
ow.
> > > > > > >
> > > > > > > > ---
> > > > > > > >  drivers/cpuidle/cpuidle-riscv-sbi.c | 24 +++++++++++++++++=
+++++--
> > > > > > > >  1 file changed, 22 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/cpuidle/cpuidle-riscv-sbi.c b/drivers/=
cpuidle/cpuidle-riscv-sbi.c
> > > > > > > > index e8094fc92491..298dc76a00cf 100644
> > > > > > > > --- a/drivers/cpuidle/cpuidle-riscv-sbi.c
> > > > > > > > +++ b/drivers/cpuidle/cpuidle-riscv-sbi.c
> > > > > > > > @@ -394,6 +394,7 @@ static int sbi_cpuidle_pd_power_off(str=
uct generic_pm_domain *pd)
> > > > > > > >  {
> > > > > > > >         struct genpd_power_state *state =3D &pd->states[pd-=
>state_idx];
> > > > > > > >         u32 *pd_state;
> > > > > > > > +       int ret;
> > > > > > > >
> > > > > > > >         if (!state->data)
> > > > > > > >                 return 0;
> > > > > > > > @@ -401,6 +402,10 @@ static int sbi_cpuidle_pd_power_off(st=
ruct generic_pm_domain *pd)
> > > > > > > >         if (!sbi_cpuidle_pd_allow_domain_state)
> > > > > > > >                 return -EBUSY;
> > > > > > > >
> > > > > > > > +       ret =3D cpu_cluster_pm_enter();
> > > > > > > > +       if (ret)
> > > > > > > > +               return ret;
> > > > > > >
> > > > > > > Rather than using the CPU cluster notifiers, consumers of the=
 genpd
> > > > > > > can register themselves to receive genpd on/off notifiers.
> > > > > > >
> > > > > > > In other words, none of this should be needed, right?
> > > > > > >
> > > > > > Thanks for the feedback!
> > > > > > Maybe I miss something, I'm wondering about a case like below:
> > > > > > If we have a shared L2 cache controller inside the cpu cluster =
power
> > > > > > domain and we add this controller to be a consumer of the power
> > > > > > domain, Shouldn't the genpd invoke the domain idle only after t=
he
> > > > > > shared L2 cache controller is suspended?
> > > > > > Is there a way that we can put the L2 cache down while all cpus=
 in the
> > > > > > same cluster are idle?
> > > > > > > [...]
> > > > > Sorry, I made some mistake in my second question.
> > > > > Update the question here:
> > > > > Is there a way that we can save the L2 cache states while all cpu=
s in the
> > > > > same cluster are idle and the cluster could be powered down?
> > > >
> > > > If the L2 cache is a consumer of the cluster, the consumer driver f=
or
> > > > the L2 cache should register for genpd on/off notifiers.
> > > >
> > > > The device representing the L2 cache needs to be enabled for runtim=
e
> > > > PM, to be taken into account correctly by the cluster genpd. In thi=
s
> > > > case, the device should most likely remain runtime suspended, but
> > > > instead rely on the genpd on/off notifiers to understand when
> > > > save/restore of the cache states should be done.
> > > >
> > > > Kind regards
> > > > Uffe