This commit 7d2078310cbf ("dt-bindings: arm: move cpu-capacity to a
shared loation") updates some references about capacity-dmips-mhz
property in this document.

The list of architectures using capacity-dmips-mhz omits RISC-V, so
supplements it here.

Signed-off-by: Song Shuai <suagrfillet@gmail.com>
---
 Documentation/scheduler/sched-capacity.rst                    | 2 +-
 Documentation/translations/zh_CN/scheduler/sched-capacity.rst | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/scheduler/sched-capacity.rst b/Documentation/scheduler/sched-capacity.rst
index 8e2b8538bc2b..e2c1cf743158 100644
--- a/Documentation/scheduler/sched-capacity.rst
+++ b/Documentation/scheduler/sched-capacity.rst
@@ -258,7 +258,7 @@ Linux cannot currently figure out CPU capacity on its own, this information thus
 needs to be handed to it. Architectures must define arch_scale_cpu_capacity()
 for that purpose.
 
-The arm and arm64 architectures directly map this to the arch_topology driver
+The arm, arm64, and RISC-V architectures directly map this to the arch_topology driver
 CPU scaling data, which is derived from the capacity-dmips-mhz CPU binding; see
 Documentation/devicetree/bindings/cpu/cpu-capacity.txt.
 
diff --git a/Documentation/translations/zh_CN/scheduler/sched-capacity.rst b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst
index e07ffdd391d3..8cba135dcd1a 100644
--- a/Documentation/translations/zh_CN/scheduler/sched-capacity.rst
+++ b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst
@@ -231,7 +231,7 @@ CFS调度类基于实体负载跟踪机制（Per-Entity Load Tracking, PELT）
 当前，Linux无法凭自身算出CPU算力，因此必须要有把这个信息传递给Linux的方式。每个架构必须为此
 定义arch_scale_cpu_capacity()函数。
 
-arm和arm64架构直接把这个信息映射到arch_topology驱动的CPU scaling数据中（译注：参考
+arm、arm64和RISC-V架构直接把这个信息映射到arch_topology驱动的CPU scaling数据中（译注：参考
 arch_topology.h的percpu变量cpu_scale），它是从capacity-dmips-mhz CPU binding中衍生计算
 出来的。参见Documentation/devicetree/bindings/cpu/cpu-capacity.txt。
 
-- 
2.20.1

On Mon, 27 Feb 2023 02:59:41 PST (-0800), suagrfillet@gmail.com wrote:
> This commit 7d2078310cbf ("dt-bindings: arm: move cpu-capacity to a
> shared loation") updates some references about capacity-dmips-mhz
> property in this document.
>
> The list of architectures using capacity-dmips-mhz omits RISC-V, so
> supplements it here.
>
> Signed-off-by: Song Shuai <suagrfillet@gmail.com>
> ---
>  Documentation/scheduler/sched-capacity.rst                    | 2 +-
>  Documentation/translations/zh_CN/scheduler/sched-capacity.rst | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/scheduler/sched-capacity.rst b/Documentation/scheduler/sched-capacity.rst
> index 8e2b8538bc2b..e2c1cf743158 100644
> --- a/Documentation/scheduler/sched-capacity.rst
> +++ b/Documentation/scheduler/sched-capacity.rst
> @@ -258,7 +258,7 @@ Linux cannot currently figure out CPU capacity on its own, this information thus
>  needs to be handed to it. Architectures must define arch_scale_cpu_capacity()
>  for that purpose.
>
> -The arm and arm64 architectures directly map this to the arch_topology driver
> +The arm, arm64, and RISC-V architectures directly map this to the arch_topology driver
>  CPU scaling data, which is derived from the capacity-dmips-mhz CPU binding; see
>  Documentation/devicetree/bindings/cpu/cpu-capacity.txt.
>
> diff --git a/Documentation/translations/zh_CN/scheduler/sched-capacity.rst b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst
> index e07ffdd391d3..8cba135dcd1a 100644
> --- a/Documentation/translations/zh_CN/scheduler/sched-capacity.rst
> +++ b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst
> @@ -231,7 +231,7 @@ CFS调度类基于实体负载跟踪机制（Per-Entity Load Tracking, PELT）
>  当前，Linux无法凭自身算出CPU算力，因此必须要有把这个信息传递给Linux的方式。每个架构必须为此
>  定义arch_scale_cpu_capacity()函数。
>
> -arm和arm64架构直接把这个信息映射到arch_topology驱动的CPU scaling数据中（译注：参考
> +arm、arm64和RISC-V架构直接把这个信息映射到arch_topology驱动的CPU scaling数据中（译注：参考
>  arch_topology.h的percpu变量cpu_scale），它是从capacity-dmips-mhz CPU binding中衍生计算
>  出来的。参见Documentation/devicetree/bindings/cpu/cpu-capacity.txt。

Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> # English
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>

Happy to take this through the RISC-V tree, but I'll hold off for a bit 
and let the doc folks have a chance to chime in (or just pick it up).  
I'm planning on sending something later this week either way.

Palmer Dabbelt <palmer@rivosinc.com> writes:

> Happy to take this through the RISC-V tree, but I'll hold off for a bit 
> and let the doc folks have a chance to chime in (or just pick it up).  
> I'm planning on sending something later this week either way.

"Doc folks" are fine if you just include this one in the pull you're
doing.

Thanks,

jon

Jonathan Corbet <corbet@lwn.net> writes:

> Palmer Dabbelt <palmer@rivosinc.com> writes:
>
>> Happy to take this through the RISC-V tree, but I'll hold off for a bit 
>> and let the doc folks have a chance to chime in (or just pick it up).  
>> I'm planning on sending something later this week either way.
>
> "Doc folks" are fine if you just include this one in the pull you're
> doing.

So it looks like that didn't happen...so I'll go ahead and apply this to
my fixes branch.

Thanks,

jon

On Mon, Feb 27, 2023 at 6:59 PM Song Shuai <suagrfillet@gmail.com> wrote:
>
> This commit 7d2078310cbf ("dt-bindings: arm: move cpu-capacity to a
> shared loation") updates some references about capacity-dmips-mhz
> property in this document.
>
> The list of architectures using capacity-dmips-mhz omits RISC-V, so
> supplements it here.
>
> Signed-off-by: Song Shuai <suagrfillet@gmail.com>
> ---
>  Documentation/scheduler/sched-capacity.rst                    | 2 +-
>  Documentation/translations/zh_CN/scheduler/sched-capacity.rst | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/scheduler/sched-capacity.rst b/Documentation/scheduler/sched-capacity.rst
> index 8e2b8538bc2b..e2c1cf743158 100644
> --- a/Documentation/scheduler/sched-capacity.rst
> +++ b/Documentation/scheduler/sched-capacity.rst
> @@ -258,7 +258,7 @@ Linux cannot currently figure out CPU capacity on its own, this information thus
>  needs to be handed to it. Architectures must define arch_scale_cpu_capacity()
>  for that purpose.
>
> -The arm and arm64 architectures directly map this to the arch_topology driver
> +The arm, arm64, and RISC-V architectures directly map this to the arch_topology driver
>  CPU scaling data, which is derived from the capacity-dmips-mhz CPU binding; see
>  Documentation/devicetree/bindings/cpu/cpu-capacity.txt.
>
> diff --git a/Documentation/translations/zh_CN/scheduler/sched-capacity.rst b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst
> index e07ffdd391d3..8cba135dcd1a 100644
> --- a/Documentation/translations/zh_CN/scheduler/sched-capacity.rst
> +++ b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst
> @@ -231,7 +231,7 @@ CFS调度类基于实体负载跟踪机制（Per-Entity Load Tracking, PELT）
>  当前，Linux无法凭自身算出CPU算力，因此必须要有把这个信息传递给Linux的方式。每个架构必须为此
>  定义arch_scale_cpu_capacity()函数。
>
> -arm和arm64架构直接把这个信息映射到arch_topology驱动的CPU scaling数据中（译注：参考
> +arm、arm64和RISC-V架构直接把这个信息映射到arch_topology驱动的CPU scaling数据中（译注：参考
>  arch_topology.h的percpu变量cpu_scale），它是从capacity-dmips-mhz CPU binding中衍生计算
>  出来的。参见Documentation/devicetree/bindings/cpu/cpu-capacity.txt。

LGTM,
Reviewed-by: Alex Shi <alexs@kernel.org>

>
> --
> 2.20.1
>

On Mon, Feb 27, 2023 at 06:59:41PM +0800, Song Shuai wrote:
> This commit 7d2078310cbf ("dt-bindings: arm: move cpu-capacity to a
> shared loation") updates some references about capacity-dmips-mhz

Not requesting a respin for this, but mentioning commit 991994509ee9
("dt-bindings: riscv: add a capacity-dmips-mhz cpu property") is
probably more relevant as a justification for this change.

> property in this document.
> 
> The list of architectures using capacity-dmips-mhz omits RISC-V, so
> supplements it here.
> 
> Signed-off-by: Song Shuai <suagrfillet@gmail.com>
> ---
>  Documentation/scheduler/sched-capacity.rst                    | 2 +-
>  Documentation/translations/zh_CN/scheduler/sched-capacity.rst | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/scheduler/sched-capacity.rst b/Documentation/scheduler/sched-capacity.rst
> index 8e2b8538bc2b..e2c1cf743158 100644
> --- a/Documentation/scheduler/sched-capacity.rst
> +++ b/Documentation/scheduler/sched-capacity.rst
> @@ -258,7 +258,7 @@ Linux cannot currently figure out CPU capacity on its own, this information thus
>  needs to be handed to it. Architectures must define arch_scale_cpu_capacity()
>  for that purpose.
>  
> -The arm and arm64 architectures directly map this to the arch_topology driver
> +The arm, arm64, and RISC-V architectures directly map this to the arch_topology driver

My grep clearly missed this change, thanks.
For the only part of the patch I understand:
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>

Thanks,
Conor.

Conor Dooley <conor.dooley@microchip.com> 于2023年2月27日周一 11:57写道：
>
> On Mon, Feb 27, 2023 at 06:59:41PM +0800, Song Shuai wrote:
> > This commit 7d2078310cbf ("dt-bindings: arm: move cpu-capacity to a
> > shared loation") updates some references about capacity-dmips-mhz
>
> Not requesting a respin for this, but mentioning commit 991994509ee9
> ("dt-bindings: riscv: add a capacity-dmips-mhz cpu property") is
> probably more relevant as a justification for this change.
>
Thanks for your correction, I'll pay attention next time.

I have a question about the patch you mentioned:
The patch uses cpu_scale per_cpu variable to store the CPU capacity
through arch_topology,
But arch_scale_cpu_capacity() interface seems not defined to deliver
the cpu_scale to the scheduler
In contrast, arm64 defines it as the topology_get_cpu_scale() in its
arch/arm64/include/asm/topology.h.
Is this an oversight or a particular purpose?

> > property in this document.
> >
> > The list of architectures using capacity-dmips-mhz omits RISC-V, so
> > supplements it here.
> >
> > Signed-off-by: Song Shuai <suagrfillet@gmail.com>
> > ---
> >  Documentation/scheduler/sched-capacity.rst                    | 2 +-
> >  Documentation/translations/zh_CN/scheduler/sched-capacity.rst | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/scheduler/sched-capacity.rst b/Documentation/scheduler/sched-capacity.rst
> > index 8e2b8538bc2b..e2c1cf743158 100644
> > --- a/Documentation/scheduler/sched-capacity.rst
> > +++ b/Documentation/scheduler/sched-capacity.rst
> > @@ -258,7 +258,7 @@ Linux cannot currently figure out CPU capacity on its own, this information thus
> >  needs to be handed to it. Architectures must define arch_scale_cpu_capacity()
> >  for that purpose.
> >
> > -The arm and arm64 architectures directly map this to the arch_topology driver
> > +The arm, arm64, and RISC-V architectures directly map this to the arch_topology driver
>
> My grep clearly missed this change, thanks.
> For the only part of the patch I understand:
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
>
> Thanks,
> Conor.
>


-- 
Thanks,
Song

On Mon, Feb 27, 2023 at 12:40:45PM +0000, Song Shuai wrote:
> Conor Dooley <conor.dooley@microchip.com> 于2023年2月27日周一 11:57写道：
> >
> > On Mon, Feb 27, 2023 at 06:59:41PM +0800, Song Shuai wrote:
> > > This commit 7d2078310cbf ("dt-bindings: arm: move cpu-capacity to a
> > > shared loation") updates some references about capacity-dmips-mhz
> >
> > Not requesting a respin for this, but mentioning commit 991994509ee9
> > ("dt-bindings: riscv: add a capacity-dmips-mhz cpu property") is
> > probably more relevant as a justification for this change.
> >
> Thanks for your correction, I'll pay attention next time.
> 
> I have a question about the patch you mentioned:
> The patch uses cpu_scale per_cpu variable to store the CPU capacity
> through arch_topology,
> But arch_scale_cpu_capacity() interface seems not defined to deliver
> the cpu_scale to the scheduler
> In contrast, arm64 defines it as the topology_get_cpu_scale() in its
> arch/arm64/include/asm/topology.h.
> Is this an oversight or a particular purpose?

Intentional oversight I suppose? It wasn't my intention to do anything
other than document the property that people were already using in
their devicetrees (and finding bugs with!).
In retrospect, perhaps it is better if I un-review this patch until
we know it is plumbed into the scheduler properly?

Ley Foon Tan is the one that found the RISC-V bugs with this property in
their devicetree, so perhaps they've already done the work here?

Thanks,
Conor.

> -----Original Message-----
> From: Conor Dooley <conor.dooley@microchip.com>
> Sent: Monday, February 27, 2023 8:56 PM
> To: Song Shuai <suagrfillet@gmail.com>
> Cc: corbet@lwn.net; alexs@kernel.org; siyanteng@loongson.cn;
> robh@kernel.org; palmer@rivosinc.com; Leyfoon Tan
> <leyfoon.tan@starfivetech.com>; linux-doc@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-riscv@lists.infradead.org
> Subject: Re: [PATCH] sched/doc: supplement CPU capacity with RISC-V
> 
> On Mon, Feb 27, 2023 at 12:40:45PM +0000, Song Shuai wrote:
> > Conor Dooley <conor.dooley@microchip.com> 于2023年2月27日周一
> 11:57写道：
> > >
> > > On Mon, Feb 27, 2023 at 06:59:41PM +0800, Song Shuai wrote:
> > > > This commit 7d2078310cbf ("dt-bindings: arm: move cpu-capacity to
> > > > a shared loation") updates some references about
> > > > capacity-dmips-mhz
> > >
> > > Not requesting a respin for this, but mentioning commit 991994509ee9
> > > ("dt-bindings: riscv: add a capacity-dmips-mhz cpu property") is
> > > probably more relevant as a justification for this change.
> > >
> > Thanks for your correction, I'll pay attention next time.
> >
> > I have a question about the patch you mentioned:
> > The patch uses cpu_scale per_cpu variable to store the CPU capacity
> > through arch_topology, But arch_scale_cpu_capacity() interface seems
> > not defined to deliver the cpu_scale to the scheduler In contrast,
> > arm64 defines it as the topology_get_cpu_scale() in its
> > arch/arm64/include/asm/topology.h.
> > Is this an oversight or a particular purpose?
> 
> Intentional oversight I suppose? It wasn't my intention to do anything other
> than document the property that people were already using in their
> devicetrees (and finding bugs with!).
> In retrospect, perhaps it is better if I un-review this patch until we know it is
> plumbed into the scheduler properly?
> 
> Ley Foon Tan is the one that found the RISC-V bugs with this property in their
> devicetree, so perhaps they've already done the work here?

I have few patches to wire up few arch_*_topology functions for RISC-V architecture. But haven't send out to ML.

Regards
Ley Foon