Conor Dooley <conor.dooley@xxxxxxxxxxxxx> 于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@xxxxxxxxx>
> > ---
> > 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@xxxxxxxxxxxxx>
>
> Thanks,
> Conor.
>
--
Thanks,
Song
