RE: [PATCH 5/9] ARC: breakout aux handling into a seperate header
>From: Vineet Gupta [mailto:vineet.gup...@synopsys.com] >Sent: Tuesday, November 1, 2016 12:48 AM >ARC timers use aux registers for programming and this paves way for moving ARC >timer drivers into drivers/clocksource Maybe in this patch or just another one could you move from timer.c to the new soc header all timer related Aux registers definitions? This could be used by timer-nps driver. i.e.: /* Timer related Aux registers */ #define ARC_REG_TIMER0_LIMIT0x23/* timer 0 limit */ #define ARC_REG_TIMER0_CTRL 0x22/* timer 0 control */ #define ARC_REG_TIMER0_CNT 0x21/* timer 0 count */ #define ARC_REG_TIMER1_LIMIT0x102 /* timer 1 limit */ #define ARC_REG_TIMER1_CTRL 0x101 /* timer 1 control */ #define ARC_REG_TIMER1_CNT 0x100 /* timer 1 count */ #define TIMER_CTRL_IE (1 << 0) /* Interrupt when Count reaches limit */ #define TIMER_CTRL_NH (1 << 1) /* Count only when CPU NOT halted */ #define ARC_TIMER_MAX 0x ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[RFC v2 7/7] mm: Remove mm-arch-hooks.h
The only use case, VDSO remap support for PowerPC, has been made generic instead of architecture-specific. Since the infrastructure is no longer needed, remove it. Signed-off-by: Christopher Covington --- arch/alpha/include/asm/Kbuild | 1 - arch/arc/include/asm/Kbuild| 1 - arch/arm/include/asm/Kbuild| 1 - arch/arm64/include/asm/Kbuild | 1 - arch/avr32/include/asm/Kbuild | 1 - arch/blackfin/include/asm/Kbuild | 1 - arch/c6x/include/asm/Kbuild| 1 - arch/cris/include/asm/Kbuild | 1 - arch/frv/include/asm/Kbuild| 1 - arch/h8300/include/asm/Kbuild | 1 - arch/hexagon/include/asm/Kbuild| 1 - arch/ia64/include/asm/Kbuild | 1 - arch/m32r/include/asm/Kbuild | 1 - arch/m68k/include/asm/Kbuild | 1 - arch/metag/include/asm/Kbuild | 1 - arch/microblaze/include/asm/Kbuild | 1 - arch/mips/include/asm/Kbuild | 1 - arch/mn10300/include/asm/Kbuild| 1 - arch/nios2/include/asm/Kbuild | 1 - arch/openrisc/include/asm/Kbuild | 1 - arch/parisc/include/asm/Kbuild | 1 - arch/s390/include/asm/Kbuild | 1 - arch/score/include/asm/Kbuild | 1 - arch/sh/include/asm/Kbuild | 1 - arch/sparc/include/asm/Kbuild | 1 - arch/tile/include/asm/Kbuild | 1 - arch/um/include/asm/Kbuild | 1 - arch/unicore32/include/asm/Kbuild | 1 - arch/x86/include/asm/Kbuild| 1 - arch/xtensa/include/asm/Kbuild | 1 - include/asm-generic/mm_hooks.h | 16 mm/mremap.c| 20 +--- 32 files changed, 17 insertions(+), 49 deletions(-) diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild index bf8475c..0a5e0ec 100644 --- a/arch/alpha/include/asm/Kbuild +++ b/arch/alpha/include/asm/Kbuild @@ -6,7 +6,6 @@ generic-y += exec.h generic-y += export.h generic-y += irq_work.h generic-y += mcs_spinlock.h -generic-y += mm-arch-hooks.h generic-y += preempt.h generic-y += sections.h generic-y += trace_clock.h diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild index c332604..e6059a8 100644 --- a/arch/arc/include/asm/Kbuild +++ b/arch/arc/include/asm/Kbuild @@ -22,7 +22,6 @@ generic-y += kvm_para.h generic-y += local.h generic-y += local64.h generic-y += mcs_spinlock.h -generic-y += mm-arch-hooks.h generic-y += mman.h generic-y += msgbuf.h generic-y += msi.h diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild index 0745538..44b717c 100644 --- a/arch/arm/include/asm/Kbuild +++ b/arch/arm/include/asm/Kbuild @@ -15,7 +15,6 @@ generic-y += irq_regs.h generic-y += kdebug.h generic-y += local.h generic-y += local64.h -generic-y += mm-arch-hooks.h generic-y += msgbuf.h generic-y += msi.h generic-y += param.h diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild index 44e1d7f..a42a136 100644 --- a/arch/arm64/include/asm/Kbuild +++ b/arch/arm64/include/asm/Kbuild @@ -20,7 +20,6 @@ generic-y += kvm_para.h generic-y += local.h generic-y += local64.h generic-y += mcs_spinlock.h -generic-y += mm-arch-hooks.h generic-y += mman.h generic-y += msgbuf.h generic-y += msi.h diff --git a/arch/avr32/include/asm/Kbuild b/arch/avr32/include/asm/Kbuild index 241b9b9..519810d 100644 --- a/arch/avr32/include/asm/Kbuild +++ b/arch/avr32/include/asm/Kbuild @@ -12,7 +12,6 @@ generic-y += irq_work.h generic-y += local.h generic-y += local64.h generic-y += mcs_spinlock.h -generic-y += mm-arch-hooks.h generic-y += param.h generic-y += percpu.h generic-y += preempt.h diff --git a/arch/blackfin/include/asm/Kbuild b/arch/blackfin/include/asm/Kbuild index 91d49c0..c80181e 100644 --- a/arch/blackfin/include/asm/Kbuild +++ b/arch/blackfin/include/asm/Kbuild @@ -21,7 +21,6 @@ generic-y += kvm_para.h generic-y += local.h generic-y += local64.h generic-y += mcs_spinlock.h -generic-y += mm-arch-hooks.h generic-y += mman.h generic-y += msgbuf.h generic-y += mutex.h diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild index 64465e7..1b9cbed 100644 --- a/arch/c6x/include/asm/Kbuild +++ b/arch/c6x/include/asm/Kbuild @@ -27,7 +27,6 @@ generic-y += kdebug.h generic-y += kmap_types.h generic-y += local.h generic-y += mcs_spinlock.h -generic-y += mm-arch-hooks.h generic-y += mman.h generic-y += mmu.h generic-y += mmu_context.h diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild index 1778805..8e98d03 100644 --- a/arch/cris/include/asm/Kbuild +++ b/arch/cris/include/asm/Kbuild @@ -24,7 +24,6 @@ generic-y += linkage.h generic-y += local.h generic-y += local64.h generic-y += mcs_spinlock.h -generic-y += mm-arch-hooks.h generic-y += mman.h generic-y += module.h generic-y += msgbuf.h diff --git a/arch/frv/include/asm/Kbuild b/arch/frv/include/asm/Kbuild index 1fa084c..2c987dc 100644 --- a/arch/frv/include/asm/Kbuild +++ b/arch/frv/include/asm/Kbuild @@ -4,7 +4,6 @@ generic-y += cputime.h generic-y +=
Re: [PATCH 9/9] clocksource: import ARC timer driver
On Mon, Oct 31, 2016 at 03:48:16PM -0700, Vineet Gupta wrote: > Signed-off-by: Vineet Gupta > --- > 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)
Re: [PATCH 9/9] clocksource: import ARC timer driver
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 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 9/9] clocksource: import ARC timer driver
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 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 9/9] clocksource: import ARC timer driver
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 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
