| Message ID | 1477954096-770-10-git-send-email-vgupta@synopsys.com |
|---|---|
| State | New |
| Headers | show |
Hi Vineet,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc3]
[cannot apply to arc/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Vineet-Gupta/Move-ARC-timer-code-into-drivers-clocksource/20161101-065452
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All error/warnings (new ones prefixed by >>):
>> drivers/clocksource/arc_timer.c:237:19: warning: 'struct clock_event_device' declared inside parameter list will not be visible outside of this definition or declaration
struct clock_event_device *dev)
^~~~~~~~~~~~~~~~~~
drivers/clocksource/arc_timer.c:243:45: warning: 'struct clock_event_device' declared inside parameter list will not be visible outside of this definition or declaration
static int arc_clkevent_set_periodic(struct clock_event_device *dev)
^~~~~~~~~~~~~~~~~~
In file included from include/asm-generic/percpu.h:6:0,
from arch/ia64/include/asm/percpu.h:45,
from arch/ia64/include/asm/processor.h:77,
from arch/ia64/include/asm/thread_info.h:11,
from include/linux/thread_info.h:58,
from include/asm-generic/preempt.h:4,
from ./arch/ia64/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:59,
from include/linux/interrupt.h:8,
from drivers/clocksource/arc_timer.c:18:
>> drivers/clocksource/arc_timer.c:253:30: error: variable 'arc_clockevent_device' has initializer but incomplete type
static DEFINE_PER_CPU(struct clock_event_device, arc_clockevent_device) = {
^
include/linux/percpu-defs.h:95:13: note: in definition of macro 'DEFINE_PER_CPU_SECTION'
__typeof__(type) name
^~~~
>> drivers/clocksource/arc_timer.c:253:8: note: in expansion of macro 'DEFINE_PER_CPU'
static DEFINE_PER_CPU(struct clock_event_device, arc_clockevent_device) = {
^~~~~~~~~~~~~~
>> drivers/clocksource/arc_timer.c:254:2: error: unknown field 'name' specified in initializer
.name = "ARC Timer0",
^
>> drivers/clocksource/arc_timer.c:254:12: warning: excess elements in struct initializer
.name = "ARC Timer0",
^~~~~~~~~~~~
drivers/clocksource/arc_timer.c:254:12: note: (near initialization for 'arc_clockevent_device')
>> drivers/clocksource/arc_timer.c:255:2: error: unknown field 'features' specified in initializer
.features = CLOCK_EVT_FEAT_ONESHOT |
^
>> drivers/clocksource/arc_timer.c:255:15: error: 'CLOCK_EVT_FEAT_ONESHOT' undeclared here (not in a function)
.features = CLOCK_EVT_FEAT_ONESHOT |
^~~~~~~~~~~~~~~~~~~~~~
>> drivers/clocksource/arc_timer.c:256:7: error: 'CLOCK_EVT_FEAT_PERIODIC' undeclared here (not in a function)
CLOCK_EVT_FEAT_PERIODIC,
^~~~~~~~~~~~~~~~~~~~~~~
drivers/clocksource/arc_timer.c:255:15: warning: excess elements in struct initializer
.features = CLOCK_EVT_FEAT_ONESHOT |
^~~~~~~~~~~~~~~~~~~~~~
drivers/clocksource/arc_timer.c:255:15: note: (near initialization for 'arc_clockevent_device')
>> drivers/clocksource/arc_timer.c:257:2: error: unknown field 'rating' specified in initializer
.rating = 300,
^
drivers/clocksource/arc_timer.c:257:14: warning: excess elements in struct initializer
.rating = 300,
^~~
drivers/clocksource/arc_timer.c:257:14: note: (near initialization for 'arc_clockevent_device')
>> drivers/clocksource/arc_timer.c:258:2: error: unknown field 'set_next_event' specified in initializer
.set_next_event = arc_clkevent_set_next_event,
^
drivers/clocksource/arc_timer.c:258:21: warning: excess elements in struct initializer
.set_next_event = arc_clkevent_set_next_event,
^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clocksource/arc_timer.c:258:21: note: (near initialization for 'arc_clockevent_device')
>> drivers/clocksource/arc_timer.c:259:2: error: unknown field 'set_state_periodic' specified in initializer
.set_state_periodic = arc_clkevent_set_periodic,
^
drivers/clocksource/arc_timer.c:259:24: warning: excess elements in struct initializer
.set_state_periodic = arc_clkevent_set_periodic,
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clocksource/arc_timer.c:259:24: note: (near initialization for 'arc_clockevent_device')
drivers/clocksource/arc_timer.c: In function 'timer_irq_handler':
>> drivers/clocksource/arc_timer.c:268:9: error: invalid use of undefined type 'struct clock_event_device'
struct clock_event_device *evt = this_cpu_ptr(&arc_clockevent_device);
^~~~~~~~~~~~~~~~~~
>> drivers/clocksource/arc_timer.c:269:36: error: implicit declaration of function 'clockevent_state_periodic' [-Werror=implicit-function-declaration]
int irq_reenable __maybe_unused = clockevent_state_periodic(evt);
^~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/clocksource/arc_timer.c:278:5: error: dereferencing pointer to incomplete type 'struct clock_event_device'
evt->event_handler(evt);
^~
drivers/clocksource/arc_timer.c: In function 'arc_timer_starting_cpu':
drivers/clocksource/arc_timer.c:286:9: error: invalid use of undefined type 'struct clock_event_device'
struct clock_event_device *evt = this_cpu_ptr(&arc_clockevent_device);
^~~~~~~~~~~~~~~~~~
>> drivers/clocksource/arc_timer.c:290:2: error: implicit declaration of function 'clockevents_config_and_register' [-Werror=implicit-function-declaration]
clockevents_config_and_register(evt, arc_timer_freq, 0, ARC_TIMER_MAX);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/clocksource/arc_timer.c: In function 'arc_clockevent_setup':
drivers/clocksource/arc_timer.c:306:9: error: invalid use of undefined type 'struct clock_event_device'
struct clock_event_device *evt = this_cpu_ptr(&arc_clockevent_device);
^~~~~~~~~~~~~~~~~~
In file included from include/asm-generic/percpu.h:6:0,
from arch/ia64/include/asm/percpu.h:45,
from arch/ia64/include/asm/processor.h:77,
from arch/ia64/include/asm/thread_info.h:11,
from include/linux/thread_info.h:58,
from include/asm-generic/preempt.h:4,
from ./arch/ia64/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:59,
from include/linux/interrupt.h:8,
from drivers/clocksource/arc_timer.c:18:
drivers/clocksource/arc_timer.c: At top level:
>> drivers/clocksource/arc_timer.c:253:50: error: storage size of 'arc_clockevent_device' isn't known
static DEFINE_PER_CPU(struct clock_event_device, arc_clockevent_device) = {
^
include/linux/percpu-defs.h:95:19: note: in definition of macro 'DEFINE_PER_CPU_SECTION'
__typeof__(type) name
^~~~
>> drivers/clocksource/arc_timer.c:253:8: note: in expansion of macro 'DEFINE_PER_CPU'
static DEFINE_PER_CPU(struct clock_event_device, arc_clockevent_device) = {
^~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/arc_clockevent_device +253 drivers/clocksource/arc_timer.c
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 231
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 232 write_aux_reg(ARC_REG_TIMER0_CTRL, TIMER_CTRL_IE | TIMER_CTRL_NH);
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 233 }
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 234
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 235
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 236 static int arc_clkevent_set_next_event(unsigned long delta,
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 @237 struct clock_event_device *dev)
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 238 {
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 239 arc_timer_event_setup(delta);
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 240 return 0;
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 241 }
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 242
aeec6cdad arch/arc/kernel/time.c Viresh Kumar 2015-07-16 243 static int arc_clkevent_set_periodic(struct clock_event_device *dev)
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 244 {
c9a98e184 arch/arc/kernel/time.c Vineet Gupta 2014-06-25 245 /*
c9a98e184 arch/arc/kernel/time.c Vineet Gupta 2014-06-25 246 * At X Hz, 1 sec = 1000ms -> X cycles;
c9a98e184 arch/arc/kernel/time.c Vineet Gupta 2014-06-25 247 * 10ms -> X / 100 cycles
c9a98e184 arch/arc/kernel/time.c Vineet Gupta 2014-06-25 248 */
77c8d0d6b arch/arc/kernel/time.c Vineet Gupta 2016-01-01 249 arc_timer_event_setup(arc_timer_freq / HZ);
aeec6cdad arch/arc/kernel/time.c Viresh Kumar 2015-07-16 250 return 0;
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 251 }
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 252
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 @253 static DEFINE_PER_CPU(struct clock_event_device, arc_clockevent_device) = {
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 @254 .name = "ARC Timer0",
aeec6cdad arch/arc/kernel/time.c Viresh Kumar 2015-07-16 @255 .features = CLOCK_EVT_FEAT_ONESHOT |
aeec6cdad arch/arc/kernel/time.c Viresh Kumar 2015-07-16 @256 CLOCK_EVT_FEAT_PERIODIC,
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 @257 .rating = 300,
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 @258 .set_next_event = arc_clkevent_set_next_event,
aeec6cdad arch/arc/kernel/time.c Viresh Kumar 2015-07-16 @259 .set_state_periodic = arc_clkevent_set_periodic,
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 260 };
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 261
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 262 static irqreturn_t timer_irq_handler(int irq, void *dev_id)
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 263 {
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 264 /*
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 265 * Note that generic IRQ core could have passed @evt for @dev_id if
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 266 * irq_set_chip_and_handler() asked for handle_percpu_devid_irq()
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 267 */
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 @268 struct clock_event_device *evt = this_cpu_ptr(&arc_clockevent_device);
31aaee97f drivers/clocksource/arc_timer.c Vineet Gupta 2016-10-31 @269 int irq_reenable __maybe_unused = clockevent_state_periodic(evt);
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 270
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 271 /*
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 272 * Any write to CTRL reg ACks the interrupt, we rewrite the
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 273 * Count when [N]ot [H]alted bit.
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 274 * And re-arm it if perioid by [I]nterrupt [E]nable bit
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 275 */
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 276 write_aux_reg(ARC_REG_TIMER0_CTRL, irq_reenable | TIMER_CTRL_NH);
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 277
f8b34c3fd arch/arc/kernel/time.c Vineet Gupta 2014-01-25 @278 evt->event_handler(evt);
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 279
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 280 return IRQ_HANDLED;
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 281 }
d8005e6b9 arch/arc/kernel/time.c Vineet Gupta 2013-01-18 282
ecd8081f6 arch/arc/kernel/time.c Anna-Maria Gleixner 2016-07-13 283
ecd8081f6 arch/arc/kernel/time.c Anna-Maria Gleixner 2016-07-13 284 static int arc_timer_starting_cpu(unsigned int cpu)
eec3c58ef arch/arc/kernel/time.c Noam Camus 2016-01-01 285 {
eec3c58ef arch/arc/kernel/time.c Noam Camus 2016-01-01 286 struct clock_event_device *evt = this_cpu_ptr(&arc_clockevent_device);
eec3c58ef arch/arc/kernel/time.c Noam Camus 2016-01-01 287
eec3c58ef arch/arc/kernel/time.c Noam Camus 2016-01-01 288 evt->cpumask = cpumask_of(smp_processor_id());
eec3c58ef arch/arc/kernel/time.c Noam Camus 2016-01-01 289
ecd8081f6 arch/arc/kernel/time.c Anna-Maria Gleixner 2016-07-13 @290 clockevents_config_and_register(evt, arc_timer_freq, 0, ARC_TIMER_MAX);
eec3c58ef arch/arc/kernel/time.c Noam Camus 2016-01-01 291 enable_percpu_irq(arc_timer_irq, 0);
ecd8081f6 arch/arc/kernel/time.c Anna-Maria Gleixner 2016-07-13 292 return 0;
eec3c58ef arch/arc/kernel/time.c Noam Camus 2016-01-01 293 }
:::::: The code at line 253 was first introduced by commit
:::::: d8005e6b95268cbb50db3773d5f180c32a9434fe ARC: Timers/counters/delay management
:::::: TO: Vineet Gupta <vgupta@synopsys.com>
:::::: CC: Vineet Gupta <vgupta@synopsys.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On 10/31/2016 05:01 PM, kbuild test robot wrote: > Hi Vineet, > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.9-rc3] > [cannot apply to arc/for-next] > [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] > [Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on] > [Check https://git-scm.com/docs/git-format-patch for more information] > > url: https://github.com/0day-ci/linux/commits/Vineet-Gupta/Move-ARC-timer-code-into-drivers-clocksource/20161101-065452 > config: ia64-allmodconfig (attached as .config) > compiler: ia64-linux-gcc (GCC) 6.2.0 > reproduce: > wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=ia64 > > All error/warnings (new ones prefixed by >>): > >>> >> drivers/clocksource/arc_timer.c:237:19: warning: 'struct clock_event_device' declared inside parameter list will not be visible outside of this definition or declaration > struct clock_event_device *dev) > ^~~~~~~~~~~~~~~~~~ > drivers/clocksource/arc_timer.c:243:45: warning: 'struct clock_event_device' declared inside parameter list will not be visible outside of this definition or declaration So I'd build tested the series for ARM (32 bit) and x86 (64 bit). Seems this requires a depends on GENERIC_CLOCKEVENTS. Will fix it along with other comments ! Thx for reporting. -Vineet
On Mon, Oct 31, 2016 at 03:48:16PM -0700, Vineet Gupta wrote: > Signed-off-by: Vineet Gupta <vgupta@synopsys.com> > --- > MAINTAINERS | 1 + > arch/arc/Kconfig | 12 +-------- > arch/arc/kernel/Makefile | 2 +- > drivers/clocksource/Kconfig | 24 ++++++++++++++++++ > drivers/clocksource/Makefile | 1 + > .../time.c => drivers/clocksource/arc_timer.c | 29 ++++++---------------- > 6 files changed, 35 insertions(+), 34 deletions(-) > rename arch/arc/kernel/time.c => drivers/clocksource/arc_timer.c (90%) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3d838cf49f81..57b56ff1dd68 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11632,6 +11632,7 @@ S: Supported > F: arch/arc/ > F: Documentation/devicetree/bindings/arc/* > F: Documentation/devicetree/bindings/interrupt-controller/snps,arc* > +F: drivers/clocksource/arc_timer.c > F: drivers/tty/serial/arc_uart.c > T: git git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git > > diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig > index b4499f97035a..8768a509d5e7 100644 > --- a/arch/arc/Kconfig > +++ b/arch/arc/Kconfig > @@ -8,9 +8,9 @@ > > config ARC > def_bool y > + select ARC_TIMER > select ARCH_SUPPORTS_ATOMIC_RMW if ARC_HAS_LLSC > select BUILDTIME_EXTABLE_SORT > - select CLKSRC_OF > select CLONE_BACKWARDS > select COMMON_CLK > select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC) > @@ -410,16 +410,6 @@ config ARC_HAS_DIV_REM > bool "Insn: div, divu, rem, remu" > default y > > -config ARC_TIMER_RTC > - bool "Local 64-bit r/o cycle counter" > - default n > - depends on !SMP > - > -config ARC_TIMER_GFRC > - bool "SMP synchronized 64-bit cycle counter" > - default y > - depends on SMP > - > config ARC_NUMBER_OF_INTERRUPTS > int "Number of interrupts" > range 8 240 > diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile > index cfcdedf52ff8..8942c5c3b4c5 100644 > --- a/arch/arc/kernel/Makefile > +++ b/arch/arc/kernel/Makefile > @@ -8,7 +8,7 @@ > # Pass UTS_MACHINE for user_regset definition > CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' > > -obj-y := arcksyms.o setup.o irq.o time.o reset.o ptrace.o process.o devtree.o > +obj-y := arcksyms.o setup.o irq.o reset.o ptrace.o process.o devtree.o > obj-y += signal.o traps.o sys.o troubleshoot.o stacktrace.o disasm.o > obj-$(CONFIG_ISA_ARCOMPACT) += entry-compact.o intc-compact.o > obj-$(CONFIG_ISA_ARCV2) += entry-arcv2.o intc-arcv2.o > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig > index e2c6e43cf8ca..73feaadc1924 100644 > --- a/drivers/clocksource/Kconfig > +++ b/drivers/clocksource/Kconfig > @@ -282,6 +282,30 @@ config CLKSRC_MPS2 > select CLKSRC_MMIO > select CLKSRC_OF > > +config ARC_TIMER > + bool "Enable timers for ARC Cores" > + select CLKSRC_OF if OF > + > +if ARC_TIMER > + > +config ARC_TIMER_RTC > + bool "64-bit cycle counter in HS38 cores" > + default y if ARC > + depends on !SMP > + help > + This counter provides 64-bit resolution vs. the 32-bit TIMER1. > + It is implemented inside the core thus can't be used in SMP systems > + > +config ARC_TIMER_GFRC > + bool "64-bit cycle counter in ARConnect block in HS38x cores" > + default y if ARC > + depends on SMP > + help > + This counter can be used as clocksource in SMP HS38 SoCs. > + It sits outside the core thus can be used in SMP systems > + > +endif > + Please stay consistent with the rest of the Kconfig. config ARC_TIMER_RTC bool "64-bit cycle counter in HS38 cores" if COMPILE_TEST select CLKSRC_OF help This counter provides 64-bit resolution vs. the 32-bit TIMER1. It is implemented inside the core thus can't be used in SMP systems. config ARC_TIMER_GFRC bool "64-bit cycle counter in ARConnect block in HS38x cores" if COMPILE_TEST select CLKSRC_OF help This counter can be used as clocksource in SMP HS38 SoCs. It sits outside the core thus can be used in SMP systems Then in the ARC's Kconfig you select ARC_TIMER_RTC or ARC_TIMER_GFRC depending it is SMP or not. One question: Why ARC_TIMER_RTC can't be used in a SMP system ? Doesn't have each core its own clocksource ? It seems you are assuming a clocksource can be used on SMP only if the clocksource is unique and shared across the cores. > config ARM_ARCH_TIMER > bool > select CLKSRC_OF if OF > diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile > index cf87f407f1ad..e78480cb47f4 100644 > --- a/drivers/clocksource/Makefile > +++ b/drivers/clocksource/Makefile > @@ -69,3 +69,4 @@ obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o > obj-$(CONFIG_H8300_TPU) += h8300_tpu.o > obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o > obj-$(CONFIG_X86_NUMACHIP) += numachip.o > +obj-$(CONFIG_ARC_TIMER) += arc_timer.o > diff --git a/arch/arc/kernel/time.c b/drivers/clocksource/arc_timer.c > similarity index 90% > rename from arch/arc/kernel/time.c > rename to drivers/clocksource/arc_timer.c > index 676b14b7a9be..ec37b6c5e903 100644 > --- a/arch/arc/kernel/time.c > +++ b/drivers/clocksource/arc_timer.c > @@ -1,32 +1,18 @@ > /* > + * Copyright (C) 2016-17 Synopsys, Inc. (www.synopsys.com) > * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com) > * > * This program is free software; you can redistribute it and/or modify > * it under the terms of the GNU General Public License version 2 as > * published by the Free Software Foundation. > - * > - * vineetg: Jan 1011 > - * -sched_clock( ) no longer jiffies based. Uses the same clocksource > - * as gtod > - * > - * Rajeshwarr/Vineetg: Mar 2008 > - * -Implemented CONFIG_GENERIC_TIME (rather deleted arch specific code) > - * for arch independent gettimeofday() > - * -Implemented CONFIG_GENERIC_CLOCKEVENTS as base for hrtimers > - * > - * Vineetg: Mar 2008: Forked off from time.c which now is time-jiff.c > */ > > -/* ARC700 has two 32bit independent prog Timers: TIMER0 and TIMER1 > - * Each can programmed to go from @count to @limit and optionally > - * interrupt when that happens. > - * A write to Control Register clears the Interrupt > - * > - * We've designated TIMER0 for events (clockevents) > - * while TIMER1 for free running (clocksource) > +/* ARC700 has two 32bit independent prog Timers: TIMER0 and TIMER1, Each can be > + * programmed to go from @count to @limit and optionally interrupt. > + * We've designated TIMER0 for clockevents and TIMER1 for clocksource > * > - * Newer ARC700 cores have 64bit clk fetching RTSC insn, preferred over TIMER1 > - * which however is currently broken > + * ARCv2 based HS38 cores have RTC (in-core) and GFRC (inside ARConnect/MCIP) > + * which are suitable for UP and SMP based clocksources respectively > */ > > #include <linux/interrupt.h> > @@ -37,7 +23,6 @@ > #include <linux/cpu.h> > #include <linux/of.h> > #include <linux/of_irq.h> > -#include <asm/irq.h> > > #include <soc/arc/timers.h> > #include <soc/arc/mcip.h> > @@ -281,7 +266,7 @@ static irqreturn_t timer_irq_handler(int irq, void *dev_id) > * irq_set_chip_and_handler() asked for handle_percpu_devid_irq() > */ > struct clock_event_device *evt = this_cpu_ptr(&arc_clockevent_device); > - int irq_reenable = clockevent_state_periodic(evt); > + int irq_reenable __maybe_unused = clockevent_state_periodic(evt); > > /* > * Any write to CTRL reg ACks the interrupt, we rewrite the > -- > 2.7.4 >
Hi Daniel, On 11/01/2016 01:42 PM, Daniel Lezcano wrote: > Please stay consistent with the rest of the Kconfig. > > config ARC_TIMER_RTC > bool "64-bit cycle counter in HS38 cores" if COMPILE_TEST > select CLKSRC_OF > help > This counter provides 64-bit resolution vs. the 32-bit TIMER1. > It is implemented inside the core thus can't be used in SMP systems. > > config ARC_TIMER_GFRC > bool "64-bit cycle counter in ARConnect block in HS38x cores" if COMPILE_TEST > select CLKSRC_OF > help > This counter can be used as clocksource in SMP HS38 SoCs. > It sits outside the core thus can be used in SMP systems > Yes I did so already :-) Although I also added a default y if ARC to both, but as you say that is better done in ARC Kconfig. > Then in the ARC's Kconfig you select ARC_TIMER_RTC or ARC_TIMER_GFRC depending > it is SMP or not. > > One question: > > Why ARC_TIMER_RTC can't be used in a SMP system ? Doesn't have each core its > own clocksource ? It seems you are assuming a clocksource can be used on SMP > only if the clocksource is unique and shared across the cores. Thats what I thought so far. Thing is, the individual core's counters could get out of sync, simply because non masters cores were halted to begin with and came up at different points in real time. so a gtod might return different value depending on what core it landed on. Does clocksource also does ticks broadcasts and such to keep things in sync ? Because of the git mv you, diff didn't include bulk of driver code which would make for bulk of review anyways. So perhaps in v2 I don't do the git mv. OK ? Thx, -Vineet
On Tue, Nov 01, 2016 at 01:57:05PM -0700, Vineet Gupta wrote: > Hi Daniel, > > On 11/01/2016 01:42 PM, Daniel Lezcano wrote: > > Please stay consistent with the rest of the Kconfig. > > > > config ARC_TIMER_RTC > > bool "64-bit cycle counter in HS38 cores" if COMPILE_TEST > > select CLKSRC_OF > > help > > This counter provides 64-bit resolution vs. the 32-bit TIMER1. > > It is implemented inside the core thus can't be used in SMP systems. > > > > config ARC_TIMER_GFRC > > bool "64-bit cycle counter in ARConnect block in HS38x cores" if COMPILE_TEST > > select CLKSRC_OF > > help > > This counter can be used as clocksource in SMP HS38 SoCs. > > It sits outside the core thus can be used in SMP systems > > > > Yes I did so already :-) Although I also added a default y if ARC to both, but as > you say that is better done in ARC Kconfig. > > > Then in the ARC's Kconfig you select ARC_TIMER_RTC or ARC_TIMER_GFRC depending > > it is SMP or not. > > > > One question: > > > > Why ARC_TIMER_RTC can't be used in a SMP system ? Doesn't have each core its > > own clocksource ? It seems you are assuming a clocksource can be used on SMP > > only if the clocksource is unique and shared across the cores. > > Thats what I thought so far. Thing is, the individual core's counters could get > out of sync, simply because non masters cores were halted to begin with and came > up at different points in real time. so a gtod might return different value > depending on what core it landed on. Does clocksource also does ticks broadcasts > and such to keep things in sync ? Sounds like it is similar than the TSC. Do you agree to have a try by setting the CONFIG_HAVE_UNSTABLE_SCHED_CLOCK option ? If you can use those per cpu clocksource, performances on your system may improve with the sched_clock(). > Because of the git mv you, diff didn't include bulk of driver code which would > make for bulk of review anyways. So perhaps in v2 I don't do the git mv. OK ? That means I will review and comment existing code. It is not a problem for me if you agree to do the changes. -- Daniel
On 11/01/2016 05:19 PM, Daniel Lezcano wrote: >>> >>> One question: >>> >>> Why ARC_TIMER_RTC can't be used in a SMP system ? Doesn't have each core its >>> own clocksource ? It seems you are assuming a clocksource can be used on SMP >>> only if the clocksource is unique and shared across the cores. >> >> Thats what I thought so far. Thing is, the individual core's counters could get >> out of sync, simply because non masters cores were halted to begin with and came >> up at different points in real time. so a gtod might return different value >> depending on what core it landed on. Does clocksource also does ticks broadcasts >> and such to keep things in sync ? > > Sounds like it is similar than the TSC. Do you agree to have a try by setting > the CONFIG_HAVE_UNSTABLE_SCHED_CLOCK option ? I'm not sure why we would want to enable extra stuff - I see work queues and bunch of per cpu counting / math to adjust for the variance, if this was enabled. Anyhow see more below. > If you can use those per cpu clocksource, performances on your system may > improve with the sched_clock(). Couple of things 1. Currently we don't hookup sched clock to any counter at all (on my todo list for a while). So we only get jiffies64 based value - I know that sucks - causes scheduling to be not super accurate etc - potentially affects benchmarks etc - but that can be fixed easily / independent of this. 2. Say we did have sched_clock() driven by hardware - in SMP system I would still prefer it to be driven by "common" GFRC and not "per cpu" RTC. The overhead of HAVE_UNSTABLE_SCHED_CLOCK looks way way more than reading GFRC counter like this. local_irq_save(flags); __mcip_cmd(CMD_GFRC_READ_LO, 0); stamp.l = read_aux_reg(ARC_REG_MCIP_READBACK); __mcip_cmd(CMD_GFRC_READ_HI, 0); stamp.h = read_aux_reg(ARC_REG_MCIP_READBACK); local_irq_restore(flags); GFRC reading by 2 cores concurrently doesn't require any synchronization at all. The irq disabling around it is to make sure we didn't get a bogus readout lest an interrupt came in between the read of 2 words. But if sched_clock can guarantee that irqs are disable - I can probably even remove it at least for the purpose of sched clock. However I think we are digressing here a bit. IMHO, what clock we choose to drive sched should not really be driven by the driver. It must be for the arch to decide. We should first focus on how the clockevent/sources are programmed first and then dive into sched_clock_xx as that doesn't exist at the moment for ARC. > >> Because of the git mv you, diff didn't include bulk of driver code which would >> make for bulk of review anyways. So perhaps in v2 I don't do the git mv. OK ? > > That means I will review and comment existing code. It is not a problem for me > if you agree to do the changes. Sure, the whole point is to make things better as an outcome of review. I have no issues changing code provided we don't add major performance regressions. Thx, -Vineet
On 11/01/2016 06:03 PM, Vineet Gupta wrote: >>> Because of the git mv you, diff didn't include bulk of driver code which would >>> >> make for bulk of review anyways. So perhaps in v2 I don't do the git mv. OK ? >> > >> > That means I will review and comment existing code. It is not a problem for me >> > if you agree to do the changes. > Sure, the whole point is to make things better as an outcome of review. I have no > issues changing code provided we don't add major performance regressions. So just wondering if I could have some comments on the initial import of driver before I send out a v2. The issue is git mv didn't show bulk of code being moved. Shall I send a v2 with a different ordering so I introduce the driver first, with new headers, new Kconfig items etc and then as a subsequent patch prune those bits from arch/arc/* ? -Vineet
On Thu, Nov 03, 2016 at 09:40:23AM -0700, Vineet Gupta wrote: > On 11/01/2016 06:03 PM, Vineet Gupta wrote: > >>> Because of the git mv you, diff didn't include bulk of driver code which would > >>> >> make for bulk of review anyways. So perhaps in v2 I don't do the git mv. OK ? > >> > > >> > That means I will review and comment existing code. It is not a problem for me > >> > if you agree to do the changes. > > Sure, the whole point is to make things better as an outcome of review. I have no > > issues changing code provided we don't add major performance regressions. > > So just wondering if I could have some comments on the initial import of driver > before I send out a v2. Yeah, ok. Let me comment the other patches of the series and then you can send a V2. > The issue is git mv didn't show bulk of code being moved. Shall I send a v2 with a > different ordering so I introduce the driver first, with new headers, new Kconfig > items etc and then as a subsequent patch prune those bits from arch/arc/* ? > > -Vineet
On Tue, Nov 01, 2016 at 01:57:05PM -0700, Vineet Gupta wrote: > Hi Daniel, > > On 11/01/2016 01:42 PM, Daniel Lezcano wrote: > > Please stay consistent with the rest of the Kconfig. > > > > config ARC_TIMER_RTC > > bool "64-bit cycle counter in HS38 cores" if COMPILE_TEST > > select CLKSRC_OF > > help > > This counter provides 64-bit resolution vs. the 32-bit TIMER1. > > It is implemented inside the core thus can't be used in SMP systems. > > > > config ARC_TIMER_GFRC > > bool "64-bit cycle counter in ARConnect block in HS38x cores" if COMPILE_TEST > > select CLKSRC_OF > > help > > This counter can be used as clocksource in SMP HS38 SoCs. > > It sits outside the core thus can be used in SMP systems > > > > Yes I did so already :-) Although I also added a default y if ARC to both, but as > you say that is better done in ARC Kconfig. > > > Then in the ARC's Kconfig you select ARC_TIMER_RTC or ARC_TIMER_GFRC depending > > it is SMP or not. > > > > One question: > > > > Why ARC_TIMER_RTC can't be used in a SMP system ? Doesn't have each core its > > own clocksource ? It seems you are assuming a clocksource can be used on SMP > > only if the clocksource is unique and shared across the cores. > As now the clksrc-probe is correctly handling the errors, if the rtc and the gfrc are both defined in the DT, you can fail to init the rtc one with a simple test in the init function: if (IS_DEFINED(CONFIG_SMP)) return -EINVAL; So, you can inconditionaly compile in both RTC and GFRC, no ? That would be cleaner and prevent a different kernel config.
Hi Daniel, On 11/03/2016 09:50 AM, Daniel Lezcano wrote: > On Thu, Nov 03, 2016 at 09:40:23AM -0700, Vineet Gupta wrote: >> On 11/01/2016 06:03 PM, Vineet Gupta wrote: >>>>> Because of the git mv you, diff didn't include bulk of driver code which would >>>>>>> make for bulk of review anyways. So perhaps in v2 I don't do the git mv. OK ? >>>>> >>>>> That means I will review and comment existing code. It is not a problem for me >>>>> if you agree to do the changes. >>> Sure, the whole point is to make things better as an outcome of review. I have no >>> issues changing code provided we don't add major performance regressions. >> >> So just wondering if I could have some comments on the initial import of driver >> before I send out a v2. > > Yeah, ok. Let me comment the other patches of the series and then you can send a V2. Thx for taking a quick look - this is a good start. How about the actual driver itself, do you want to take a quick look there as well before v2 ? > >> The issue is git mv didn't show bulk of code being moved. Shall I send a v2 with a >> different ordering so I introduce the driver first, with new headers, new Kconfig >> items etc and then as a subsequent patch prune those bits from arch/arc/* ?
On Thu, Nov 03, 2016 at 10:57:48AM -0700, Vineet Gupta wrote: > Hi Daniel, > > On 11/03/2016 09:50 AM, Daniel Lezcano wrote: > > On Thu, Nov 03, 2016 at 09:40:23AM -0700, Vineet Gupta wrote: > >> On 11/01/2016 06:03 PM, Vineet Gupta wrote: > >>>>> Because of the git mv you, diff didn't include bulk of driver code which would > >>>>>>> make for bulk of review anyways. So perhaps in v2 I don't do the git mv. OK ? > >>>>> > >>>>> That means I will review and comment existing code. It is not a problem for me > >>>>> if you agree to do the changes. > >>> Sure, the whole point is to make things better as an outcome of review. I have no > >>> issues changing code provided we don't add major performance regressions. > >> > >> So just wondering if I could have some comments on the initial import of driver > >> before I send out a v2. > > > > Yeah, ok. Let me comment the other patches of the series and then you can send a V2. > > Thx for taking a quick look - this is a good start. How about the actual driver > itself, do you want to take a quick look there as well before v2 ? At the first glance, with your changes it is acceptable to be moved. Perhaps, you can have a look to remove the BIG_ENDIAN stuff in the clock read function.
On Thu, Nov 03, 2016 at 06:33:17PM +0100, Daniel Lezcano wrote: [ ... ] > As now the clksrc-probe is correctly handling the errors, if the rtc and the > gfrc are both defined in the DT, you can fail to init the rtc one with a simple > test in the init function: > > if (IS_DEFINED(CONFIG_SMP)) > return -EINVAL; > > So, you can inconditionaly compile in both RTC and GFRC, no ? That would be > cleaner and prevent a different kernel config. Ah, actually I suggested something which is already there :) Perhaps, the if SMP does not make sense in the Kconfig, no ?
On 11/03/2016 11:11 AM, Daniel Lezcano wrote: >> Thx for taking a quick look - this is a good start. How about the actual driver >> > itself, do you want to take a quick look there as well before v2 ? > At the first glance, with your changes it is acceptable to be moved. Perhaps, > you can have a look to remove the BIG_ENDIAN stuff in the clock read function. > OK addressed that as well !
On 11/03/2016 10:33 AM, Daniel Lezcano wrote: > As now the clksrc-probe is correctly handling the errors, if the rtc and the > gfrc are both defined in the DT, you can fail to init the rtc one with a simple > test in the init function: > > if (IS_DEFINED(CONFIG_SMP)) > return -EINVAL; > > So, you can inconditionaly compile in both RTC and GFRC, no ? That would be > cleaner and prevent a different kernel config. That's a very good idea. So now I envision CONFIG_ARC_TIMERS # legacy TIMER0 / TIMER1 CONFIG_ARC_64BIT_TIMERS # rtc, gfrc I need this distinction at the min to be able to select them from ARC Kconfig. -Vineet
diff --git a/MAINTAINERS b/MAINTAINERS index 3d838cf49f81..57b56ff1dd68 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11632,6 +11632,7 @@ S: Supported F: arch/arc/ F: Documentation/devicetree/bindings/arc/* F: Documentation/devicetree/bindings/interrupt-controller/snps,arc* +F: drivers/clocksource/arc_timer.c F: drivers/tty/serial/arc_uart.c T: git git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index b4499f97035a..8768a509d5e7 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -8,9 +8,9 @@ config ARC def_bool y + select ARC_TIMER select ARCH_SUPPORTS_ATOMIC_RMW if ARC_HAS_LLSC select BUILDTIME_EXTABLE_SORT - select CLKSRC_OF select CLONE_BACKWARDS select COMMON_CLK select GENERIC_ATOMIC64 if !ISA_ARCV2 || !(ARC_HAS_LL64 && ARC_HAS_LLSC) @@ -410,16 +410,6 @@ config ARC_HAS_DIV_REM bool "Insn: div, divu, rem, remu" default y -config ARC_TIMER_RTC - bool "Local 64-bit r/o cycle counter" - default n - depends on !SMP - -config ARC_TIMER_GFRC - bool "SMP synchronized 64-bit cycle counter" - default y - depends on SMP - config ARC_NUMBER_OF_INTERRUPTS int "Number of interrupts" range 8 240 diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile index cfcdedf52ff8..8942c5c3b4c5 100644 --- a/arch/arc/kernel/Makefile +++ b/arch/arc/kernel/Makefile @@ -8,7 +8,7 @@ # Pass UTS_MACHINE for user_regset definition CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' -obj-y := arcksyms.o setup.o irq.o time.o reset.o ptrace.o process.o devtree.o +obj-y := arcksyms.o setup.o irq.o reset.o ptrace.o process.o devtree.o obj-y += signal.o traps.o sys.o troubleshoot.o stacktrace.o disasm.o obj-$(CONFIG_ISA_ARCOMPACT) += entry-compact.o intc-compact.o obj-$(CONFIG_ISA_ARCV2) += entry-arcv2.o intc-arcv2.o diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index e2c6e43cf8ca..73feaadc1924 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -282,6 +282,30 @@ config CLKSRC_MPS2 select CLKSRC_MMIO select CLKSRC_OF +config ARC_TIMER + bool "Enable timers for ARC Cores" + select CLKSRC_OF if OF + +if ARC_TIMER + +config ARC_TIMER_RTC + bool "64-bit cycle counter in HS38 cores" + default y if ARC + depends on !SMP + help + This counter provides 64-bit resolution vs. the 32-bit TIMER1. + It is implemented inside the core thus can't be used in SMP systems + +config ARC_TIMER_GFRC + bool "64-bit cycle counter in ARConnect block in HS38x cores" + default y if ARC + depends on SMP + help + This counter can be used as clocksource in SMP HS38 SoCs. + It sits outside the core thus can be used in SMP systems + +endif + config ARM_ARCH_TIMER bool select CLKSRC_OF if OF diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile index cf87f407f1ad..e78480cb47f4 100644 --- a/drivers/clocksource/Makefile +++ b/drivers/clocksource/Makefile @@ -69,3 +69,4 @@ obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o obj-$(CONFIG_H8300_TPU) += h8300_tpu.o obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o obj-$(CONFIG_X86_NUMACHIP) += numachip.o +obj-$(CONFIG_ARC_TIMER) += arc_timer.o diff --git a/arch/arc/kernel/time.c b/drivers/clocksource/arc_timer.c similarity index 90% rename from arch/arc/kernel/time.c rename to drivers/clocksource/arc_timer.c index 676b14b7a9be..ec37b6c5e903 100644 --- a/arch/arc/kernel/time.c +++ b/drivers/clocksource/arc_timer.c @@ -1,32 +1,18 @@ /* + * Copyright (C) 2016-17 Synopsys, Inc. (www.synopsys.com) * Copyright (C) 2004, 2007-2010, 2011-2012 Synopsys, Inc. (www.synopsys.com) * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. - * - * vineetg: Jan 1011 - * -sched_clock( ) no longer jiffies based. Uses the same clocksource - * as gtod - * - * Rajeshwarr/Vineetg: Mar 2008 - * -Implemented CONFIG_GENERIC_TIME (rather deleted arch specific code) - * for arch independent gettimeofday() - * -Implemented CONFIG_GENERIC_CLOCKEVENTS as base for hrtimers - * - * Vineetg: Mar 2008: Forked off from time.c which now is time-jiff.c */ -/* ARC700 has two 32bit independent prog Timers: TIMER0 and TIMER1 - * Each can programmed to go from @count to @limit and optionally - * interrupt when that happens. - * A write to Control Register clears the Interrupt - * - * We've designated TIMER0 for events (clockevents) - * while TIMER1 for free running (clocksource) +/* ARC700 has two 32bit independent prog Timers: TIMER0 and TIMER1, Each can be + * programmed to go from @count to @limit and optionally interrupt. + * We've designated TIMER0 for clockevents and TIMER1 for clocksource * - * Newer ARC700 cores have 64bit clk fetching RTSC insn, preferred over TIMER1 - * which however is currently broken + * ARCv2 based HS38 cores have RTC (in-core) and GFRC (inside ARConnect/MCIP) + * which are suitable for UP and SMP based clocksources respectively */ #include <linux/interrupt.h> @@ -37,7 +23,6 @@ #include <linux/cpu.h> #include <linux/of.h> #include <linux/of_irq.h> -#include <asm/irq.h> #include <soc/arc/timers.h> #include <soc/arc/mcip.h> @@ -281,7 +266,7 @@ static irqreturn_t timer_irq_handler(int irq, void *dev_id) * irq_set_chip_and_handler() asked for handle_percpu_devid_irq() */ struct clock_event_device *evt = this_cpu_ptr(&arc_clockevent_device); - int irq_reenable = clockevent_state_periodic(evt); + int irq_reenable __maybe_unused = clockevent_state_periodic(evt); /* * Any write to CTRL reg ACks the interrupt, we rewrite the
Signed-off-by: Vineet Gupta <vgupta@synopsys.com> --- MAINTAINERS | 1 + arch/arc/Kconfig | 12 +-------- arch/arc/kernel/Makefile | 2 +- drivers/clocksource/Kconfig | 24 ++++++++++++++++++ drivers/clocksource/Makefile | 1 + .../time.c => drivers/clocksource/arc_timer.c | 29 ++++++---------------- 6 files changed, 35 insertions(+), 34 deletions(-) rename arch/arc/kernel/time.c => drivers/clocksource/arc_timer.c (90%)