Hi Dietmar,
On 19/01/17 16:00, Dietmar Eggemann wrote:
> On 19/01/17 14:37, Juri Lelli wrote:
> > arm and arm64 share lot of code relative to parsing CPU capacity
> > information from DT, using that information for appropriate scaling and
> > exposing a sysfs interface for chaging such values at runtime.
> >
> > Factorize such code in a common place (driver/base/arch_topology.c) in
> > preparation for further additions.
> >
> > Suggested-by: Will Deacon <will.deacon@xxxxxxx>
> > Suggested-by: Mark Rutland <mark.rutland@xxxxxxx>
> > Suggested-by: Catalin Marinas <catalin.marinas@xxxxxxx>
> > Cc: Russell King <linux@xxxxxxxxxxxxxxx>
> > Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
> > Cc: Will Deacon <will.deacon@xxxxxxx>
> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> > Signed-off-by: Juri Lelli <juri.lelli@xxxxxxx>
> > ---
> > arch/arm/Kconfig | 1 +
> > arch/arm/kernel/topology.c | 213 ++------------------------------------
> > arch/arm64/Kconfig | 1 +
> > arch/arm64/kernel/topology.c | 213 +-------------------------------------
> > drivers/base/Kconfig | 8 ++
> > drivers/base/Makefile | 1 +
> > drivers/base/arch_topology.c | 240 +++++++++++++++++++++++++++++++++++++++++++
> > 7 files changed, 260 insertions(+), 417 deletions(-)
> > create mode 100644 drivers/base/arch_topology.c
>
> [...]
>
> > +extern unsigned long
> > +arch_scale_cpu_capacity(struct sched_domain *sd, int cpu);
>
> How about adding a driver specific prefix 'foo_' to all driver interfaces?
>
> I'm asking because I would rather like to do a
>
> #define arch_scale_cpu_capacity foo_scale_cpu_capacity
>
> then a
>
> #define arch_scale_cpu_capacity arch_scale_cpu_capacity
>
> in arch/arm64/include/asm/topology.h
>
> later to wire cpu-invariant load-tracking support up to the task
> scheduler for ARM64.
>
> That's probably true too for all the 'driver' interfaces which get used
> in arch/arm{,64}/kernel/topology.c.
>
Looks like a good way to improve clarity to me. I'll add a patch for the
next version doing this and we see what people think.
Best,
- Juri
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
